API 版本管理与 ABI 稳定性

需要关注两种兼容性：

• 应用程序接口兼容性——针对版本 N 编译的源代码，也能针对 N+1 编译
• ABI 兼容性——针对版本 N 编译的二进制文件无需重新编译，即可与 N+1 配合工作

ABI 兼容性允许在不重新编译依赖方的情况下升级共享库。这对软件发行版、插件和长期运行的应用程序至关重要。

许多看似无害的更改都会破坏 ABI：

• 添加、删除或重新排列数据成员
• 添加或删除虚函数
• 更改继承关系
• 更改模板参数
• 更改内联函数（有时）

通过版本号 MAJOR.MINOR.PATCH 表示兼容性：

• MAJOR——不兼容的更改
• MINOR——向后兼容的新功能
• PATCH——修复

请在头文件中提供版本宏。

在 Linux 上，共享库具有编码主版本号的 SONAME。链接器和加载器使用它来查找兼容版本。

稳定的 ABI 要求不要将实现放在头文件中。请使用 PIMPL（下一课介绍），以便在不影响使用方的情况下添加或删除私有成员。

不同编译器之间的 C++ ABI 各不相同（GCC 与 MSVC 使用不同的名称修饰和类布局）。请发布使用特定编译器构建的二进制文件，或坚持使用 extern "C" 接口。

标准库也可能破坏 ABI，不过 libstdc++ 和 libc++ 都有相应策略。如果需要跨版本兼容，请避免在稳定的公共应用程序接口中使用标准库类型。

安全的添加方式：

• 新增自由函数
• 新增类
• 新增非虚成员函数（需谨慎）

不安全的做法：修改使用方在栈上创建或已编译进其中的类。

用于比较两个构建结果的工具：

• abidiff——比较 ABI
• abicompliance-checker——生成报告

请从一开始就为稳定性进行设计：采用小型公共应用程序接口、不透明类型，并谨慎使用模板和继承。一旦发布，破坏 ABI 的代价就很高——将不兼容的更改限定在主版本升级中，并清晰地进行沟通。

应用程序接口兼容性意味着源代码兼容性；ABI 兼容性意味着二进制兼容性。ABI 很脆弱——添加成员、虚函数或更改继承关系都会破坏它。请使用 SemVer，通过 PIMPL 隐藏实现，同时发布多个主版本，并运行 ABI 检查工具。