ABI兼容性是跨编译器传递C++对象的核心障碍，因类布局、虚表、名称修饰、异常处理等二进制约定不一致；唯一安全方式是退至C ABI，用extern "C"接口和opaque handle隔离实现。
跨编译器传递对象时，指针本身不是问题，ABI 才是核心障碍
直接用裸指针（比如 MyClass*）在不同编译器（如 MSVC 和 Clang/GCC）之间传递对象，几乎必然崩溃或未定义行为。这不是指针语法的问题，而是因为不同编译器对类布局、虚表结构、名字修饰（name mangling）、异常处理机制、RTTI 实现等底层约定不一致——也就是 ABI（Application Binary Interface）不兼容。
你不能指望 MSVC 编译的 std::string 对象能被 Clang 安全解引用；也不能把 g++ 生成的带虚函数的类指针，交给 clang++ 的代码去 delete。
唯一安全的方式：用 C 风格 ABI 做边界隔离
跨编译器二进制互操作，必须退回到 C ABI 层——它稳定、无名修饰、无例外、无虚函数、无重载、无模板。所有对象交互都要通过纯 C 函数接口暴露。
- 导出函数必须用
extern "C"声明，禁用 C++ name mangling - 对象生命周期完全由 C 接口管理：用
create_thing()/destroy_thing(ThingHandle)，而不是暴露new/delete - 内部状态封装为 opaque handle（例如
typedef struct Thing* ThingHandle），外部只传指针，不访问成员 - 数据交换避免 C++ 类型：字符串用
const char*+ 长度，容器用回调或预分配缓冲区
示例接口：
立即学习“C++免费学习笔记（深入）”；
extern "C" {
typedef struct MyObject* MyObjectHandle;
<pre class="brush:php;toolbar:false;">MyObjectHandle create_object(int x);
void destroy_object(MyObjectHandle obj);
int get_value(MyObjectHandle obj);}
为什么不能用 std::shared_ptr 或 unique_ptr 跨编译器传递
std::shared_ptr 看似自动管理内存，但它依赖编译器特定的控制块布局、原子操作实现、以及析构器类型擦除方式。MSVC 的 shared_ptr 控制块和 GCC 的大小/字段顺序不同，直接传递会导致 use_count 错乱、双重析构或崩溃。
- 即使两个编译器都用 libc++ 或 libstdc++，只要版本不同，
std::shared_ptr的二进制结构也可能不兼容 -
unique_ptr更危险：它的删除器类型是模板参数，跨编译器无法保证调用同一段析构逻辑 - 任何含模板实例化的类型（包括
std::vector,std::string）都不能作为函数参数或返回值跨 ABI 边界
Windows DLL 场景下特别要注意的坑
在 Windows 上用 DLL 分发 C++ 类，哪怕同是 MSVC，不同版本（如 VS2019 vs VS2022）也可能因 STL 内部变更导致崩溃。更别说混用 Clang-CL 和 MSVC。
- 不要导出 class 定义（即避免
__declspec(dllexport)类），只导出 C 函数 - 避免 DLL 中使用静态链接的 C++ 运行时（
/MT），否则new/delete不匹配；优先用动态运行时（/MD），但即便如此，STL 对象仍不可跨 DLL 边界传递 - 若必须共享内存布局，可考虑用
#pragma pack+ 显式alignas+ 手动序列化，但仅限 POD 类型，且需双方严格同步头文件
真正健壮的跨编译器对象传递，从来不是“怎么让指针工作”，而是“怎么绕过指针直接操作对象”——把对象变成黑盒，只留 C 函数门面。这点容易被忽略，但一旦越界，调试成本远高于初期多写几个封装函数。
