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

51–60 of 89 posts

Re: Thoroughly Understanding C++ ABI (2024)

#51

Post by rramadass »

mohamedkoubaa wrote: post #33
bluGill wrote: post #21

Earlier quoted context omitted.

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

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.

Re: Thoroughly Understanding C++ ABI (2024)

#53

Post by [deleted] »

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…

[deleted]

Re: Thoroughly Understanding C++ ABI (2024)

#54

Post by rramadass »

pjmlp wrote: post #49
rramadass wrote: post #48

Earlier quoted context omitted.

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.

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

Re: Thoroughly Understanding C++ ABI (2024)

#56

Post by pjmlp »

rramadass wrote: post #54
pjmlp wrote: post #49

Earlier quoted context omitted.

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.

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?

Re: Thoroughly Understanding C++ ABI (2024)

#57

Post by mohamedkoubaa »

rramadass wrote: post #51
mohamedkoubaa wrote: post #33

Earlier quoted context omitted.

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

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.

Re: Thoroughly Understanding C++ ABI (2024)

#58

Post by uecker »

bluGill wrote: post #21
mohamedkoubaa wrote: post #13

Earlier quoted context omitted.

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.

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.

Re: Thoroughly Understanding C++ ABI (2024)

#59

Post by quotemstr »

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

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

Just add async_uuid to your IDL locally and rerun MIDL. The server doesn't know or care that it's being called asynchronously. It's a pure client thing. If you're calling an IFoo in a different apartment, you can do the call asynchronously by changing your client configuration without the IFoo implementation having to be aware that anything is going on.

You can also use IRpcChannelBuffer3 to make the call asynchronously no matter what the IDL says. You'll have to write the proxy plumbing yourself, but it'll work, and you don't even need to rerun MIDL.

Re: Thoroughly Understanding C++ ABI (2024)

#60

Post by Maxatar »

MFHava wrote: post #34
bluGill wrote: post #20

Earlier quoted context omitted.

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

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

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

Post reply on HN