Hacker News Reader

Comment by jdw64 | Hacker News Reader

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.

View on HN

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

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

One more addition.

There is often a distinction made between "language ABI" and "library ABI" in documentation which is highly confusing.

The answer is: library API + compiler ABI = library ABI

GNU libstdc++ ABI Policy and Guidelines - https://gcc.gnu.org/onlinedocs/gcc-9.2.0/libstdc++/manual/ma...

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 either use other systems languages, or expose their OS APIs in a different way, e.g. mainframes, micros, Android, ChromeOS, WebOS,...

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

Android is Linux and it's written in C. Bionic is still a posix libc.

Android uses the Linux kernel as implementation detail, it could be changed with Zircon if Google cared, bionic is partially POSIX, only the required for ISO C, ISO C++, ART and NDK native APIs is exposed.

80% of Android APIs are exposed via Java, and even native ones have to use JNI.

Additionally a lot of the APIs if you go underneath, including native code components, are exposed through few variants of Binder (BeOS-derived IPC for the uninitiated) including userspace drivers.

Binder APIs very much do not follow C ABI other than the part where you deal with wrapper around ioctl()

This is entirely unrelated to the point made.

Binder is just C++ with a thin IPC compiler, more or less similar to any IPC idl. Could be sunrpc, but Google wanted a c++ wrapper.

But in any case this is completely irrelevant, because there is no such thing as a "userspace driver" (unless you're speaking about hurd or plan9). Drivers are by definition kernel-space code (which on Linux is either built into the kernel, or is a loadable kernel module). Those binder wrappers are just a convenience layer, underneath it's all still Linux, /dev/video0, v4l2, and so on.

Linux actually has pretty long history of userspace drivers, and multiple kernel drivers have as their main if not only logic a way to link hardware interface with userspace app, or just providing transport interface. And android heavily uses such interfaces from day 0, which is why you have separate binder instance on Android for drivers.

As for Binder being C++, no it isn't. Historically it has connection with C++ due to how it was used, but like other IPC it's not bound to C++, and arguably given how it is structured compared to some other options there's even less C++ specific stuff in it.

Also, IIRC the use of Binder predates acquisition of Danger (?) by Google

It's just demagoguery. Windows could switch to Linux kernel if Microsoft cared enough to invest into Wine. But this will not happen any time soon.

All smartphone drivers would have to be rewritten for a different kernel.

One reason. The other is C is easy. Any language can implement it and have confidence it can work. (there are other options that are just as easy, but C won). C++ is much harder because of things like function overloading and exceptions - none of it is difficult, but there is a lot more to do and thus more opportunities for bugs.

I would go far as to say that modern C++ is an Eldritch horror of a programming experience

Unfortunately no one is going to rewrite LLVM, GCC, CUDA, DirectX, Metal, SYSCL, V8,... into something else.

Same applies to C and UNIX/POSIX, OpenGL/Vulkan/OpenCL/NVN/LibGNM(X),...

Thus analysers and language subsetting tools, enforcing language style guides and safer coding practices.

Oh come on; that is BS and you know it.

It is complex/complicated/baroque but for the power, flexibility, real-world-usage that it provides it is worth the effort. The mistake that people make is to try and learn it all at the same time which overwhelms them.

Use a good book like Discovering Modern C++: An Intensive Course for Scientists, Engineers, and Programmers by Peter Gottschling and you should have no problem at all.

For context: I have over a decade of professional experience with c++ in large scale software projects and it is by far the language over which I have the most mastery.

And yet you make such statements ;-)

I often see on HN these sorts of comments whenever C++ is brought up and it really needs to stop. It is wrong, adds no value to the discussion and does a grave injustice to the programming community.

We should be encouraging programmers to learn C/C++ since just knowing those two languages enables one to program MCU/embedded/desktop/server machines across all layers of software from apps/scientific software/OS/system software/bare-metal in the real-world. One can imagine the job opportunities for a programmer with such a skillset as market needs change. With both Hardware and Software evolving so rapidly nowadays, C/C++ are the one constant interface language in the industry.

I would encourage programmers to learn c++ because it's important, but I'll never lie about what it's like to actually use it

You don't have to lie or play-up/play-down the language; just say it as it is with no painting of dragons and fear-mongering.

It is just another language and not rocket science.

Easy and still expressive, so you can map many things to C. And while the language standard does not define an ABI it takes a lot of care not to require any ABI break.

> With exception of Swift, D, and bytecode based languages, the ABI is left to the vendors.

I don’t see exceptions there. Apple defines the ABI of Apple’s Swift’s implementation, Walter Bright (or his team) defines that of D, Python defines its ABI, etc.

If you were to write a Swift/D/etc compiler, you’re free to define your own ABI. Disadvantage is that you would give up linking with code compiled by the other compiler (workarounds such as pragmas, C++’s extern "C", are possible)

You're missing who defines the language standard.

You're free to do whatever you feel like on your implementation, including not being compliant with the official language standard.

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.

> They then watched the gcc community work through 10 years of pain to make the transition.

During the same time the MSVC compiler broke ABI multiple times and the world didn't end.

The fact that breaking ABI was such a shitshow for libstc++ is more related to the way C++/ABI/SOs is/are handled in Linux...

In the time since that VC++ has switched to a frozen ABI model that’s much closer to what Linux distros have. Each version of VC++ being ABI-incompatible and requiring each application to be built with a single version and ship its c++ runtime had some significant pros and cons.

Microsoft never said it outright, but I’ve always assumed the major con that made them switch was that people didn’t buy new Visual Studio versions because upgrading VS required also upgrading all of your binary blob closed-source dependencies.

The reason the world didn't end is because people refused to upgrade Visual Studio, in particular Microsoft's bigger customers. Microsoft surveyed their users for why people weren't making the switch to VS 2013 despite all the "nice" and "new" features introduced and the predominant reason was due to all the ABI breakages.

For VS 2015 they adopted a policy of having a stable ABI and have preserved ABI compatibility for over 10 years now [1].

[1] https://devblogs.microsoft.com/cppblog/binary-compatibility-...

The part where Windows applications built with C++ generally do not share C++ ABI DLLs with each other and the operating system except for certain well isolated ones is major part of it.

GCC changing C++ ABI usually meant horrific time for every C++ application on Linux unless you use something like Nix so you don't chance loading incompatible binaries.

When the C++ standards committee make decisions crippling the language to preserve ABI (see std::regex), it's defacto part of the standard.

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?

Probably, but note that Google says they are they main customer anyway, and it is an experiment above anything else.

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.

Reply on news.ycombinator.com