是什么变化导致C++中ABI中断

虽然没有常见的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被烘焙到太多的库中，以至于它只会被更改。