跨编译器C++ DLL与应用交互：COM接口及结构体返回问题咨询

你选择的纯虚接口+C风格导出函数的COM式方案，是实现跨编译器DLL交互的经典可靠路径，下面针对你的疑问逐一解答：

问题1：同架构下标准类型的跨编译器大小一致性 #

• 对于基础标准类型（int、float、char、指针等），同CPU架构（如x86/x64）下的主流编译器都会遵循对应平台的ABI规范（比如Windows的x86/x64 ABI），因此实际大小是一致的。但要注意：C++标准本身仅规定了这些类型的最小范围（例如int至少16位），并没有强制固定大小。
• 保障一致性的方法：
  • 优先使用<cstdint>头文件中的固定大小类型，比如int32_t、uint64_t、intptr_t等，这些类型的大小是C++标准明确规定的，跨编译器绝对一致。
  • 如果必须使用int、unsigned这类依赖平台的类型，务必在文档中明确其对应架构下的大小（例如Windows x86/x64下int均为32位）。
  • 指针类型：同架构下的指针大小完全由CPU决定（x86为32位，x64为64位），所有编译器的实现必然一致。

问题2：COM接口中传递结构体、标准库类型的兼容性 #

结构体的跨编译器可行性与陷阱 #

• 传递/返回仅由标准基础类型组成的结构体是可行的，但需警惕内存布局差异：
  • 字段顺序：C++标准明确要求结构体字段按声明顺序布局，只要双方头文件的结构体声明完全一致，字段顺序不会有问题。
  • 对齐方式：这是最容易出问题的点。不同编译器的默认对齐规则可能不同（例如VC默认8字节对齐，GCC部分场景默认4字节对齐），甚至同一编译器的编译选项（如VC的/Zp）也会改变对齐策略。
  • 规避方案：
    1. 在结构体声明时显式指定对齐规则，比如使用跨平台宏统一对齐方式：

       #ifdef _MSC_VER
       #pragma pack(push, 4)
       #else
       #pragma pack(4)
       #endif
       struct NodeInfo {
           int32_t id;
           const char* name;
       };
       #ifdef _MSC_VER
       #pragma pack(pop)
       #else
       #pragma pack()
       #endif
       

    2. 优先传递结构体的指针/引用而非实例：这能规避传递时的拷贝对齐问题，但本质仍需保证双方结构体的内存布局完全一致，否则指针指向的内存解析会出错。

标准库类型（如std::vector）的跨编译器兼容性 #

• 绝对禁止在跨编译器接口中传递或返回std::vector、std::string等标准库容器：
  • 核心原因：不同编译器（甚至同一编译器的不同版本）对标准库容器的内部实现细节差异极大，比如std::vector的内存分配器、内部成员布局（部分实现用3个指针，部分用封装结构体）都不统一，跨编译器传递必然导致内存错误或逻辑异常。
  • 替代方案：
    1. 采用C风格的数组+长度组合：例如返回const char*传递字符串，或返回元素指针+输出参数传递数组长度（如const INode** get_children(size_t* out_count)），同时提供对应的资源销毁函数（如void free_children(const INode** children)）。
    2. 自定义纯虚接口模拟容器功能：比如定义INodeCollection接口，提供get_count()、get_node(size_t index)等方法，完全封装容器实现细节。

额外的最佳实践与禁忌 #

• 必须通过extern "C"导出的C风格函数创建/销毁对象，禁止调用方直接使用new/delete——不同编译器的内存分配器不兼容，跨编译器释放内存会导致崩溃。
• 接口必须是纯虚类：不能包含非虚函数或数据成员，Windows下主流编译器（VC++、GCC、Clang）的虚函数表布局规则一致，纯虚接口的调用是可靠的。
• 禁止在接口函数中抛出C++异常：不同编译器的异常处理机制不兼容，应使用错误码（如你的EResultCode）传递错误信息。
• 统一调用约定：显式指定函数的调用约定（如Windows下的__stdcall或__cdecl），避免因调用约定不匹配导致的栈溢出错误，例如：

  virtual EResultCode add_child(INode* node) noexcept __stdcall = 0;
  extern "C" {
      LIB_API INode* __stdcall create_node();
      LIB_API void __stdcall destroy_node(const INode* node);
  }
  

内容的提问来源于stack exchange，提问作者Alex Nem