[gok]

C++ ABI issues seem to be in this paradoxical situation where the language standard powerbrokers simultaneously feel that

a. Having a real binary compatibility story is beneath C++, but

b. The accidental ABI compatibility that exists today is too widely adopted to break.

[olliej]

Basically every modern platform (eg free of 90s mistakes) uses the itanium ABI, which defines vtable layout, RTTI layout.

But platforms define the final memory and calling conventions so that can’t be part of any language spec - this is not unique to C++.

Windows has its own ABI, which it has had for a long time, so they can’t change it, so on x86 windows it will always be that.

[Rusky]

The ABI discussed here is a bit higher level than that. Even with a fixed ABI for vtables, calling conventions, etc. you still have to care about what happens when you change a "vocabulary type" in the standard library- some changes are source-compatible but binary-breaking.

For example, C++11 broke ABI at this level by changing the representation of std::string.

[olliej]

Oof I was unaware of the string ABI break (just had to look it up) - that’s kind of gross :-/

That said in general ABI compatibility is expected of all changes, without very good reasons - security seems like a good one, performance alas not - I assume std::string got the small string optimization because they were already going to break ABI for the threading issues.

Of course it doesn’t help that c++ is still C like so implementations/use of data layout gets compiled directly into the client application :-/