使用std::unique_ptr的PImpl惯用法能否保证ABI兼容性？

结论很明确：在相同硬件、操作系统环境下，采用std::unique_ptr管理Impl对象的PImpl惯用法，并不能100%保证ABI兼容性，原因如下：

• std::unique_ptr的内存布局未被C标准规定
  C标准只定义了std::unique_ptr的行为，没有强制要求它的字节大小或内部结构。不同STL实现（比如GCC的libstdc++、Clang的libc++），甚至同一STL的不同版本，都可能对unique_ptr做差异化设计：

  • 例如Debug模式下，部分STL会给unique_ptr添加额外的调试跟踪字段，导致其大小大于Release模式；
  • 即使是Release模式，不同STL可能因对齐策略、内部优化等差异，让unique_ptr的字节大小出现变化。

• 跨STL编译会破坏MyClass的内存布局一致性
  当库和客户端使用不同STL编译时，MyClass中m_impl成员（即std::unique_ptr<Impl>）的大小会不一致，直接导致MyClass的整体大小和内存布局跨模块不匹配。这种情况下，跨API边界传递MyClass对象、调用成员函数时，会出现内存越界、调用栈错乱等ABI兼容问题。

• 实现严格ABI兼容的替代方案
  如果需要在相同硬件/OS环境下确保ABI稳定，应该用原始指针存储Impl对象，手动在析构函数中管理内存释放。原始指针的大小由硬件架构决定（如64位系统固定为8字节），在相同环境下是完全一致的，能彻底避免STL差异带来的ABI风险。

补充说明：如果库和客户端使用完全相同的STL版本编译，std::unique_ptr的大小和布局是一致的，此时PImpl可以保证ABI兼容；但只要STL存在差异，就存在兼容性风险。

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