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

41–50 of 79 posts

Re: Thoroughly Understanding C++ ABI (2024)

#41

Post by mort96 »

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

Not only, there is also XPC and IO/DriverKit on Apple, Android IPC, D-BUS, FIDL on Fucshia,.... 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…

Uh, GNU does define an OS ABI...

Re: Thoroughly Understanding C++ ABI (2024)

#42

Post by pjmlp »

rramadass wrote: post #29
quotemstr wrote: post #25

Earlier quoted context omitted.

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

COM is heavily used in Windows today, no need for past tense.

Re: Thoroughly Understanding C++ ABI (2024)

#43

Post by pjmlp »

mort96 wrote: post #41
pjmlp wrote: post #7

Earlier quoted context omitted.

Not only, there is also XPC and IO/DriverKit on Apple, Android IPC, D-BUS, FIDL on Fucshia,.... 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…

Uh, GNU does define an OS ABI...

Documentation....

Re: Thoroughly Understanding C++ ABI (2024)

#44

Post by jdw64 »

rramadass wrote: post #35
jdw64 wrote: post #6

Earlier quoted context omitted.

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…

Asking questions is always a good thing so don't worry about it. It makes us think and check our own understanding too, so we also learn something :-) A nice succinct post by Pavel Khaipov; Copy-on-Write in Modern C++: Why the Standard Dropped It - and Why Qt Still Uses It - https://www.linkedin.com/posts/khaipov_copy-on-write-in-mode... A detailed post by Andrii Nikishaiev; Why Copy-On-Write (COW) removed in C++? -…

I'm sorry for always bothering you, senior. I've learned quite a lot from the books you recommended. I've especially been studying low-level topics lately, and the books you suggested have been very helpful. Have a great day.

Re: Thoroughly Understanding C++ ABI (2024)

#46

Post by Someone »

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…

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

Re: Thoroughly Understanding C++ ABI (2024)

#47

Post by throwlifeaway »

WalterBright wrote: post #30
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.)

You mean... using a vtable? Are you claiming to have invented the concept of vtables?

Re: Thoroughly Understanding C++ ABI (2024)

#48

Post by rramadass »

pjmlp wrote: post #42
rramadass wrote: post #29

Earlier quoted context omitted.

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

COM is heavily used in Windows today, no need for past tense.

Not directly by app developers. Everybody uses only WinRT/.NET based managed languages/runtimes/libraries/frameworks etc.

Re: Thoroughly Understanding C++ ABI (2024)

#49

Post by pjmlp »

rramadass wrote: post #48
pjmlp wrote: post #42

Earlier quoted context omitted.

COM is heavily used in Windows today, no need for past tense.

Not directly by app developers. Everybody uses only WinRT/.NET based managed languages/runtimes/libraries/frameworks etc.

Who uses WinRT besides Microsoft employees, or APIs that are only available in WinRT like MIDI 2.0?

Regardless, WinRT is COM.

It only adds IInspectable as additional interface alongside IUnknown, and .NET metadata files instead of type libraries.

Re: Thoroughly Understanding C++ ABI (2024)

#50

Post by pjmlp »

Someone wrote: post #46
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…

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

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.

Post reply on HN