在extern "C" DLL中使用std::string_view是否符合跨语言ABI要求？

首先明确结论：C++标准并未强制保证std::string_view和std::span的内存布局是{T; size_t;}*，哪怕cppreference列出了它们的数据成员，那也只是对典型实现的描述，而非标准层面的强制要求。

为什么不能依赖std::string_view的布局？ #

C++标准只规定了这些类型的行为接口（比如data()、size()方法的返回值，迭代器的行为等），但完全没有约束它们的内存结构。不同编译器（如MSVC、GCC、Clang）甚至同一编译器的不同版本，都可能在不违反标准的前提下调整布局——比如添加对齐填充、调整成员顺序（虽然概率极低，但标准允许），这对跨语言ABI调用来说是致命的：Python或C#端如果硬按{const char*; size_t;}来定义对应结构体，一旦编译器布局变化，就会出现内存访问错误、数据错乱等问题。

更稳妥的方案：自定义跨语言兼容结构体 #

为了彻底保障Python和C#的调用兼容性，建议自行定义明确布局的结构体，比如：

extern "C" {
    // 对应字符串视图的自定义结构体
    struct StringView {
        const char* data;  // 指向字符串数据的指针
        size_t length;     // 字符串长度（无需以'\0'结尾）
    };

    // 通用的Span结构体
    template<typename T>
    struct Span {
        T* data;
        size_t length;
    };
}

这种自定义结构体的优势在于：

• 完全可控内存布局，跨语言映射时没有歧义：Python用ctypes.Structure定义对应结构，C#用[StructLayout(LayoutKind.Sequential)]标记结构体即可完美匹配
• 明确传递非所有权语义，和std::string_view的设计目标一致
• 同样支持已知长度、无需空字符结尾的特性，满足你的需求

对cppreference描述的补充 #

cppreference中列出的“数据成员”是对主流编译器实现的总结，并非标准强制要求。标准允许编译器在不破坏公开接口行为的前提下，对内部结构做任意调整——这也是C++标准库类型的常见设计原则：只保证行为，不保证布局。

内容的提问来源于stack exchange，提问作者Dominik Kaszewski