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

21–30 of 79 posts

Re: Thoroughly Understanding C++ ABI (2024)

#21

Post by bluGill »

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

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.

Re: Thoroughly Understanding C++ ABI (2024)

#22

Post by pjmlp »

Mond_ wrote: post #11
andyg_blog wrote: post #8

Earlier quoted context omitted.

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.

Re: Thoroughly Understanding C++ ABI (2024)

#23

Post by rramadass »

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.

COM designers were inspired by C++ but their goals were different. They were designing a language-neutral binary standard (aka ABI) and hence took C++'s approach and tweaked it for their specification.

Here is an earlier comment of mine with some details - https://news.ycombinator.com/item?id=49142987

Re: Thoroughly Understanding C++ ABI (2024)

#24

Post by aw1621107 »

jdw64 wrote: post #6
rramadass wrote: post #3

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

I understand that Move Semantics led to better implementations and that this is why things changed. I know that in this case, problems arose when transitioning from C++98 to what's commonly called Modern C++ (C++11). However, I'm not very familiar with what the specific issues were with COW. If you happen to know of any documents that describe this problem in more detail, I'd appreciate it if you could let me know. I…

The changes to std::string were made because "the [pre-C++11] definition of basic_string allows only very limited concurrent access to strings. Such limited concurrency will inhibit performance in multi-threaded applications." The proposed fix was to make "all iterator and element access operations safely concurrently executable." [0]. This involved limiting the circumstances in which iterators could be invalidated, which among other things meant that non-const operator[] could no longer invalidate iterators, which meant copy-on-write was no longer a viable implementation [1].

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n26...

[1]: https://stackoverflow.com/q/12199710

Re: Thoroughly Understanding C++ ABI (2024)

#25

Post by quotemstr »

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.

And COM enforces lifecycle rules, transparent remoting, uniform activation (constructors basically), security primitives, marshalling, transparent async calls (yes, you can call any method asynchronously), and a ton of other things. It's actually very good and it's a shame most don't know about it and most of the rest sneer at it.

Re: Thoroughly Understanding C++ ABI (2024)

#26

Post by jeffbee »

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.

Re: Thoroughly Understanding C++ ABI (2024)

#27

Post by leni536 »

mohamedkoubaa wrote: post #18
leni536 wrote: post #16

Earlier quoted context omitted.

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.

Yes and no. The Linux kernel barely interacts with the C calling convention ABI (vDSO), and you can interact with the OS without going through a C library. I guess the layout of some structs are exposed through some binary protocols, but most of them are not C function calls.

Re: Thoroughly Understanding C++ ABI (2024)

#28

Post by dblohm7 »

quotemstr wrote: post #25
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.

And COM enforces lifecycle rules, transparent remoting, uniform activation (constructors basically), security primitives, marshalling, transparent async calls (yes, you can call any method asynchronously), and a ton of other things. It's actually very good and it's a shame most don't know about it and most of the rest sneer at it.

I agree!

(Though you cannot call just any method asynchronously; the interface's IDL needs specific annotations and the underlying object needs to implement ICallFactory.)

Re: Thoroughly Understanding C++ ABI (2024)

#29

Post by rramadass »

quotemstr wrote: post #25
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.

And COM enforces lifecycle rules, transparent remoting, uniform activation (constructors basically), security primitives, marshalling, transparent async calls (yes, you can call any method asynchronously), and a ton of other things. It's actually very good and it's a shame most don't know about it and most of the rest sneer at it.

Well said.

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.

Re: Thoroughly Understanding C++ ABI (2024)

#30

Post by WalterBright »

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.

> and a very specific vtable layout for COM objects

Fun fact: Microsoft developed COM based on how Zortech C++ virtual functions worked. (It predated Microsoft C++ by years.)

Post reply on HN