Thoroughly Understanding C++ ABI (2024)

C++ ABIs are why Win32 settled on things like COM to do cross-module passing of objects. Because nobody could agree on a standard, the COM standard enforced a very specific calling convention, and a very specific vtable layout for COM objects.

As always, read wikipedia and follow links as needed - https://en.wikipedia.org/wiki/Application_binary_interface

GNU libstdc++ "Dual ABI" issue - https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a...

One nice thing to remember is for projects you control, you can dictate the ABI. There isn't a law enforcement bureau that will arrest you for passing parameters in whatever register suits you. You just have to imagine life differently than they did in the 70s when they dreamed up dynamic libraries for reasons that are largely no longer valid.

Does the C++ standard guarantee binary ABI? Isn't that something that compiler and library contributors handle separately? So I think the arguments you see online are more accurate—vendors are the ones maintaining it.

In other words, the ABI we rely on today isn't really part of the C+ standard—it's more like the Itnaium C++ ABI or the MSVC C++ ABI.

In the end, I think the ABI stays stable because of community conventions established by compiler vendors.

C++ famously has no ABI, it is the implementations of C++ that have ABIs. The reason the situation is so bad is that it's considered explicitly out of scope of the language (it targets an abstract machine).