Live data from Hacker News

Thoroughly Understanding C++ ABI (2024)

ykiko.me

61–70 of 79 posts

Re: Thoroughly Understanding C++ ABI (2024)

#61
post #7
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…

System V ABI is pretty standardized.

Re: Thoroughly Understanding C++ ABI (2024)

#62

Earlier quoted context omitted.

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

Yes, the vtable. Microsoft at the time equipped their COM team with Zortech C++ and so they used the Zortech vtable. No, I did not invent the concept of vtables.

Re: Thoroughly Understanding C++ ABI (2024)

#63
post #56

Earlier quoted context omitted.

I said " WinRT/.NET based managed languages/runtimes/libraries/frameworks" implying that it is the higher-level constructs that are used by app developers. If you were to interview any "standard" windows programmer today i can almost guarantee they know nothing about COM even though WinRT itself is an evolution of COM and .NET also provides COM interop. Only the older senior programmers who have used it directly know…

Ignoring C++ devs on purpose? Also no one uses WinUI, if that is what you are implying with WinRT, only Microsoft employees on Windows team forced to deal with that clusterfuck framework after Project Reunion pivoted into WinAppSDK. What do you think Qt, VCL, FireMonkey, ImGui, wxWindgets, JUCE make use of?

What are you talking about? None of it is relevant to the point i am making.

Also you do not need COM to program in C/C++ directly on Windows API since they are all C interfaces anyway. COM is just an architecture you choose to use or not depending upon your needs.

Ever since managed languages/virtual machines became "standard" programming platforms most Windows programmers only write to these. Everything is at such a high-level now that only curious programmers delve deeper into the rabbit-hole.

Re: Thoroughly Understanding C++ ABI (2024)

#64

Earlier quoted context omitted.

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…

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.

Re: Thoroughly Understanding C++ ABI (2024)

#65
post #56

Earlier quoted context omitted.

Ignoring C++ devs on purpose? Also no one uses WinUI, if that is what you are implying with WinRT, only Microsoft employees on Windows team forced to deal with that clusterfuck framework after Project Reunion pivoted into WinAppSDK. What do you think Qt, VCL, FireMonkey, ImGui, wxWindgets, JUCE make use of?

What are you talking about? None of it is relevant to the point i am making. Also you do not need COM to program in C/C++ directly on Windows API since they are all C interfaces anyway. COM is just an architecture you choose to use or not depending upon your needs. Ever since managed languages/virtual machines became "standard" programming platforms most Windows programmers only write to these. Everything is at such…

You definitely do, unless you are stuck in Windows XP view of computing world.

It is like using ReactOS instead.

All Windows APIs since Vista are delivered via COM.

How much Windows development are you doing actually?

Not that much apparently.

Also someone has to surface Windows APIs to managed languages, they don't appear by magic.

Re: Thoroughly Understanding C++ ABI (2024)

#66
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…

System V ABI is pretty standardized.

UNIX, the reason why C exists.

Re: Thoroughly Understanding C++ ABI (2024)

#68
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…

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