Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoroughly Understanding C++ ABI (2024)

ykiko.me

Post reply on HN
Print view View original

11–20 of 79 posts

Re: Thoroughly Understanding C++ ABI (2024)

#11

Post by Mond_ »

andyg_blog wrote: post #8
jdw64 wrote: post #5

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 conven…

It doesn't, and FWIW the article says that. A meta note: ABI stability is a holy war inside the C++ community. Those against it argue that it's holding back real language evolution. Herb Sutter is even working on his own C++ offshoot that shows what could be.

Afaik Herb Sutter largely stopped working on Cppfront a few months ago, and was never quite supposed to be a real thing, just a personal playground (or so Sutter claims at this point, anyway).

Afaik Carbon is at this point the only attempt at a successor language that's still going?

Re: Thoroughly Understanding C++ ABI (2024)

#13

Post by mohamedkoubaa »

pjmlp wrote: post #10
jdw64 wrote: post #5

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 conven…

No, neither does the C standard. 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 eit…

Isn't this one reason why C is the de facto FFI? OSes happen to use it in their OS ABI and so everything is forced to speak it

Re: Thoroughly Understanding C++ ABI (2024)

#14

Post by jdw64 »

jcranmer wrote: post #9
jdw64 wrote: post #5

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 conven…

No, ABI is not part of the C++ standard, although there are parts of C++ that do go "this is an ABI thing" (e.g., [[no_unique_address]]). 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 convent…

Thank you for the kind comment. I'll make a note of it and look into it.

Re: Thoroughly Understanding C++ ABI (2024)

#15

Post by mohamedkoubaa »

Dwedit wrote: post #4

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.

Given OOP, the only ABI for an object is a vtable and that is left unspecified (for good reason) by the C++ standard.

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

Re: Thoroughly Understanding C++ ABI (2024)

#16

Post by leni536 »

mohamedkoubaa wrote: post #12

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).

Neither of the ISO C and ISO C++ standards define an ABI.

Re: Thoroughly Understanding C++ ABI (2024)

#17

Post by pjmlp »

mohamedkoubaa wrote: post #13
pjmlp wrote: post #10

Earlier quoted context omitted.

No, neither does the C standard. 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 eit…

Isn't this one reason why C is the de facto FFI? OSes happen to use it in their OS ABI and so everything is forced to speak it

OS written the C, which is what many overlook.

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,...

Re: Thoroughly Understanding C++ ABI (2024)

#18

Post by mohamedkoubaa »

leni536 wrote: post #16
mohamedkoubaa wrote: post #12

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).

Neither of the ISO C and ISO C++ standards define an ABI.

Right, C doesn't specify an ABI either but (many) OSes do and they provide their ABIs in C so C became the defacto ABI of a given platform.

Re: Thoroughly Understanding C++ ABI (2024)

#19

Post by pjmlp »

mohamedkoubaa wrote: post #15
Dwedit wrote: post #4

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.

Given OOP, the only ABI for an object is a vtable and that is left unspecified (for good reason) by the C++ standard. 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

SOM predates COM, and is even cooler, as it supported class inheritance, metaclasses and Smalltalk as target language.

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.

Re: Thoroughly Understanding C++ ABI (2024)

#20

Post by bluGill »

jdw64 wrote: post #5

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 conven…

The C++ standard doesn't say anything about binary ABI (as you say generally either Itanium or MSVC, though there are other options they are rare). However the people who write that standard are very sensitive to the vendors and users of C++ who depend on a stable binary ABI. Thus they take extreme care to ensure that no change to the standard breaks binary ABI.

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.

Post reply on HN