[1] Herb Sutter's C++ ABI effort was supposed to solve exactly this, but unfortunately never went anywhere. The proposal document pinpoints the problem very well in my opinion: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n40...
[1] Herb Sutter's C++ ABI effort was supposed to solve exactly this, but unfortunately never went anywhere. The proposal document pinpoints the problem very well in my opinion: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n40...
We have not attempted to constrain the interface [of the standard library] at this level, because we do not consider doing so feasible at this time
So it wasn't necessarily out of scope, it was just hard to do.I think the reason they don't consider it feasible, is because the C++ ABI would constrain the implementation significantly and there was too much divergence already.
AFAIK MSVC compilers explicitly guarantee ABI compatibility since 2015 https://learn.microsoft.com/en-us/cpp/porting/binary-compat-...
as for other platforms, all compilers adhere to Itanium ABI and didnt introduce breaking changes for many years now. Standard libraries, libc++ has explicit ABI guarantee as well (https://libcxx.llvm.org/DesignDocs/ABIVersioning.html).
Libstdc++ uses symbol versioning and only nasty thing happened to it was problem with std::string CoW decade ago, but even that was done neatly and in compatible manner https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a...
But the parent comment's point is that, even for those different compilers that do follow that inter-compiler ABI, the standard libraries have different binary layouts from other compilers. Your final two links show that GCC and LLVM standard libraries each have the same binary layout as itself between different versions, but not as the other.