Thoroughly Understanding C++ ABI(ykiko.me) |
Thoroughly Understanding C++ ABI(ykiko.me) |
Also C ABI also does not exist, people keep mistaking the ABI of their favourite C compiler with the OS ABI, which only overlap if the OS was written in C to start with.
For example on mainframes and micros, naturally not written in C, it is either a bytecode based ABI like TIMI on IBM i, or language environments like on z/OS, ClearPath MCP, OS 2200 and so forth.
And as a reminder, from a famous WG14 and WG21 member, and former Rust contributor,
"To Save C, We Must Save ABI"
https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-funct...
(Though you cannot call just any method asynchronously; the interface's IDL needs specific annotations and the underlying object needs to implement ICallFactory.)
COM was one of the best realizations of "Component-based Software Engineering" and Brad Cox's "Software-IC" model. It was a binary standard and so components could be written in any language and yet be assured of perfect interoperability provided you followed all the rules/conventions. There was a bunch of boiler-plate for the framework itself but once you understood it, everything was smooth sailing in your language of choice.
One of the things i always advise people is not to focus only on the current way of doing things but to study older well-known libraries/frameworks/architectures/kernels/etc. to really understand "Software Engineering" from many perspectives. That is where insight comes from and real understanding happens.
For people interested in understanding COM, see the classic Essential COM by Don Box.
Here is an earlier comment of mine with some details - https://news.ycombinator.com/item?id=49142987
COM said, "objects are cool and modules are cool so we need an ABI for objects" and specified a vtable. It isn't the only programming model which continued from the same observation: Python did too with its absolutely abysmal leaky PyObject ABI
On OS/2, Smalltalk enjoyed a role similar to what would be .NET and VB on Windows.
Sure you can use delegation with aggregation, and type libraries (nowadays .NET metadata), but still isn't as ergonomic.
[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n26...
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.
ABI is more of OS-level thing. Most systems these days follow the SysV ABI, which is largely defined by the hardware manufacturers via the processor-specific supplements (the x86-64 one is here: https://gitlab.com/x86-psABIs/x86-64-ABI). These largely delegate C++-specific conventions to the Itanium C++ ABI (which they likely directly reference), although the ARM ecosystem uses a somewhat different layout for the exception handling tables. Microsoft uses a different ABI for both the underlying C ABI and for the C++ compatibility layer built on top of the C ABI.
One of the issues that crops up is that vendors end up needing to add extensions to the ABI for various reasons, and these extensions tend to end up being incompatible, since they're added before they've had a time to be standardized. 16-bit floats is a particular historical bugbear, as is the C23 _BitInt stuff.
With exception of Swift, D, and bytecode based languages, the ABI is left to the vendors.
For those that think ISO/IEC 9899:2024 PDF has anything related to ABI, the actual ABI used by C compilers, is the OS ABI, if the OS was written in C to start with, and naturally this overlaps quite nicely with UNIX like OSes, and Windows.
It isn't like that on other platforms that decided to either use other systems languages, or expose their OS APIs in a different way, e.g. mainframes, micros, Android, ChromeOS, WebOS,...
The C++ standard did force gcc to break the ABI of std::string (copy on write was banned - for good reason). They then watched the gcc community work through 10 years of pain to make the transition. They are also well aware that python 3 broke compatibility with Python 2 - and again it resulted in 10 years of pain for the python community to deal with that. With this history there are a lot of experts strongly against any breaking change. It might happen anyway, but only with strong justification and likely an attempt at a migration of some form (what? there are a lot of examples of migration plans that don't work that they are aware of)
Again, it is not because of convention, it is because of painful experience from those who break it.
Afaik Carbon is at this point the only attempt at a successor language that's still going?
If you are on e.g. z/OS you would be using ILE, Integrated Language Environment, on ChromeOS JS/WASM, on Android either DEX or JNI,...
Anyone that can reach out to Rust, Go, Java, C#, whatever, should do that preferably.
There are also some efforts to tame existing C++ with profiles, and replacing UB with erroneous behaviour, and that's about it.