c++ - 什么变化导致 C++ 中的 ABI 中断？

Question

当 C++ 标准化委员会调查 STL 的修改时，非常注意不要引入 ABI 破坏性更改。

是什么导致了 ABI 中断，什么没有在 C++ 中引入 ABI 中断？ ((欢迎链接到专注于此的类(class)或文档)

Answer 1

虽然没有通用的 ABI，但标准委员会确实听取了供应商对一些供应商报告的 ABI 损坏提出的担忧。这些担忧是否会阻止做出改变取决于改变的内容。

对于标准库，导致潜在 ABI 破坏的主要问题是那些改变类或类模板的布局或改变典型内联函数的行为的问题。大多数情况下，问题可以通过稍微不同的表述或稍微移动功能来解决。

对于 C++11，我记得关于 ABI 的相关讨论 std::list<...>::size()为 std::basic_string<...> 设置恒定时间和 COW 实现被禁止。对于列表问题，问题不在于因为大多数实现无论如何都已经使用了恒定的时间大小，而少数没有使用的时间大小则不能成为足够强大的案例。对于 std::basic_string<...>用于 COW 实现的 ABI 被破坏了，因为不为不同字符串对象提供数据竞争保证的缺点是 Not Acceptable 。

对于提出的一些建议，例如，为 std::exception 强制堆栈跟踪的想法。这会破坏每个人的异常 ABI，ABI 破坏几乎是一个致命的论点。尽管有时会引入强制 ABI 中断更改的更改，但与不影响任何内容的更改相比，必须对案例进行更强有力的争论:除非更改的好处超过报告的破坏某些供应商 ABI 的可能性，否则不会完成.在一些有争议的案例中，实现者回过头来调查是否有机会实现一个可能稍微低效的版本以实现向后兼容性。

ABI 的问题在于，如果不能将旧库与新编译器一起使用，肯定会有公司大声提示。在某些情况下，供应商会提供开关来支持它们，例如 std::string被烘焙到太多的库中，以至于它只会被更改。