Vin*_*ent 13 c++ standards compatibility abi c++11
当C++标准化委员会调查STL的修改时,要特别注意不引入ABI破坏性变化.
是什么导致ABI破坏以及什么不引入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被捆绑到太多的库中,只会被改变.