当C ++标准化委员会调查STL的修改时，会引起很大的注意，不会引入ABI突破性变化。
是什么导致ABI破坏以及什么不引入C ++中的ABI破坏？ （（欢迎关注课程或文件的链接）
答案 0 :(得分：7)
虽然没有共同的ABI，但标准委员会确实听取供应商对某些供应商报告的ABI破损的担忧。关注是否阻止改变取决于改变的内容。
对于标准库，导致潜在ABI破坏的主要问题是那些改变类或类模板的布局或改变通常内联函数的行为的问题。大多数情况下，问题可以通过稍微不同的表述或稍微移动功能来解决。
对于C ++ 11，我记得有关ABI的相关讨论，std::list<...>::size()被定为常量时间，而std::basic_string<...>被禁止的COW实现。对于列表问题，问题并非如此，因为大多数实现已经使用了恒定的时间大小，而少数几个没有做出足够强大的情况。对于std::basic_string<...>，COW实现的ABI被破坏了，因为不能为不同的字符串对象提供数据争用保证的缺点是不可接受的。
对于提出的一些提案，例如强制要求std::exception的堆栈跟踪的想法会破坏每个人的异常ABI，ABI破坏几乎是一个杀手级的论点。虽然有时会引入要求ABI突破变更的变更，但是这个案例必须比不影响任何事情的变更强有力：除非变更的好处超过报告的破坏某些供应商的ABI的潜力，否则将无法完成。在一些有争议的案例中，实施者回过头来调查是否有可能为了向后兼容而实施一个可能略微低效的版本。
ABI的问题在于，如果他们不能将旧库与新编译器一起使用，肯定会有大声抱怨的公司。在某些情况下，供应商提供支持它们的开关，但是，例如，std::string被捆绑到太多的库中，只会被更改。