What changes causes an ABI breaking in C++?

Question

When the C++ standardization committee investigates modifications of the STL, a large attention is taken to not introduce ABI breaking changes.

What causes ABI breaking and what do not introduce ABI breaking in C++ ? ((link to courses or document focused on that are welcome)

Answer 1

Although there is no common ABI, the standard committee does listen to vendor raising concerns about ABI breakage being reported by some vendors. Whether the concerns stop a change from being made depends on what is being changed.

For the standard library the primary issues causing potential ABI breakage are those which change the layout of a class or a class template or the changing the behavior of typically inlined functions. Most of the time the issues can be resolved by a slightly different formulation or by moving functionality a bit around.

For C++11 I remember ABI related discussions about std::list<...>::size() being made constant time and a COW implementation for std::basic_string<...> being prohibited. For the list issue the problem wasn't that because most implementations already used a constant time size anyway and the few which didn't couldn't make a strong enough case. For std::basic_string<...> the ABI for COW implementations was broken because the drawback of not making data race guarantees for different string objects was just not acceptable.

For some of the proposals which were brought forward, e.g., the idea of mandating a stack trace for std::exceptions which would break everybody's exception ABI, the ABI breakage is pretty much a killer argument. Although changes which mandate ABI breaking changes are sometimes introduced, the case has to be argued a lot stronger than changes which don't affect anything: unless the benefit of the change outweights the reported potential of breaking some vendor's ABI it won't be done. In some contentious cases the implementers went back and investigated if there is a chance to implement a potentially slight inefficient version for backward compatibility.

The issue with ABIs is that there are definitely companies who will complain loudly if they can't use their old libraries with the new compilers. In some cases the vendors provide switches to support them but, e.g., std::string is baked into too many libraries that it would just be changed.