Hacker News Reader

Comment by hwc | Hacker News Reader

A common issue with C++ software is the need for a stable, standard ABI, which C provides but C++ does not (except through `extern "C"`). Because C++ name mangling is not standardized and the standard library headers have tons of implementation-specific details, something like `void foo(std::unique_ptr<Bar>);` does not have a stable ABI.

View on HN

In practice, there is a stable and standard ABI in C++. On Windows systems, you use the (undocumented, but mostly reverse-engineered) MSVC ABI. On everybody else, you use the confusingly-named Itanium ABI, except for exception handling on ARM, which uses a slightly different ABI.

Standard library implementations do not necessarily share the same ABI, but it is possible to interoperate between libc++ and libstdc++, and libstdc++ maintains ABI compatibility across different versions.

And, to be pedantic, C does not provide a stable, standard ABI. It is the platforms themselves that provide this ABI standard, and these platforms equally provide a C++ ABI standard. So C++ ABI compatibility is no more or less a problem than C ABI compatibility.

Just a small correction macOS derived platforms do it a bit differently as well.

The legitimate difference between C and C++ ABIs is that the C ABI is easier to understand and reason about.

It's analogous to Java and Scala; each has an ABI, but it's easier to tell when the former breaks ABI than the latter.

That's right. C being more limited, it has a more simplistic ABI. But the parent comment was replying the "need for a stable, standard ABI, which C provide". Which is misleading as both C++ and C have the same level of stability and standardisation of their ABI. (I.e: none of them is standardized, but both of them are stable on practice)

Yep, you're right.

There is a difference, but the difference is in complexity, not availability.

> common issue with C++ software is the need for a stable, standard ABI.

That's not entirely true. C++ has a stable ABI: compiling a library with GCC and reusing it with clang or ICC is doable and commonly done nowadays.

The problem with the C++ ABI is that it is shamefully fragile. It is extremely easy to break an ABI without wanting it in C++, even for experts.

https://community.kde.org/Policies/Binary_Compatibility_Issu...

> standard ABI, which C provides but C++ does not

Neither the C Language Standard nor the C++ Language Standard specify an ABI.

> Neither the C Language Standard nor the C++ Language Standard specify an ABI.

Perhaps we should distinguish between a Langage-Standard ABI vs. a per-platform de facto ABI.

I think the GP's comment holds for the latter definition.

I don't believe that either the GCC or MSVC C ABIs have been the same (per platform) over the years.

For C: both platform have been EXTREMELY compatible over the years. They probably both treat breakage as bug. This is a must given the fundamental APIs are defined in term of C headers, and must remain compatible.

Even for C++: gcc has been mostly compatible, but not unreasonably so. MSVC was traditionally not at all, but has recently been for 2 or 3 major versions in a row. I think MSVC will eventually break it again though, but at least they break it way less often than before (and breaking can also have advantages).

What does that have to do with lifetime annotations?

how is that related in any way to the article ?

Also, I don’t think there is anything in the C, respectively C++ standards that forbids, respectively requires name mangling. Linking isn’t specified in either standard.

C++ implementations have name mangling because they live on systems designed for C, which don’t allow symbols such as int max(int,int)

C implementations (would) need name mangling if they ran on a system that used case-insensitive comparisons on symbol names, or on ones whose character set is smaller than that allowed in C symbols (I know examples of neither, but Wikipedia has an example that encodes the calling convention in the symbol name: https://en.wikipedia.org/wiki/Name_mangling#C)

The table in that article shows how different compilers mange very similarly but not the same! This is something that could be standardized for the benefit of all.

Not quite. You would know what to call, but not how to call it. That would require full ABI compatibility, and C++’s is complex. https://isocpp.org/wiki/faq/compiler-dependencies#binary-com...:

”If name mangling was standardized, could I link code compiled with compilers from different compiler vendors?

Short answer: Probably not.”

(click link for more info)

Thanks for the info. I'm just a C/C++ user. There has to be way to workout a convention for all those options.

> Probably not.

yet the real life answer is that I can link C++ code built with three different compiler on linux (gcc / clang / icc) and three / two on windows (clang / cl.exe / icc or clang / gcc)

Reply on news.ycombinator.com