Rendered at 11:51:52 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Dwedit 21 hours ago [-]
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.
pjmlp 21 hours ago [-]
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/OS, ClearPath MCP, OS 2200 and so forth.
And as a reminder, from a famous WG14 and WG21 member, and former Rust contributor,
Yeah, I'm not interested in decoding what you meant by your aphorism. Either say what you mean or don't.
pjmlp 1 hours ago [-]
Great, so lets save us both time.
mort96 19 hours ago [-]
Uh, GNU does define an OS ABI...
pjmlp 18 hours ago [-]
Documentation....
mort96 18 hours ago [-]
You're gonna have to be more verbose, sorry.
pjmlp 18 hours ago [-]
It is kind of obvious, GNU OS ABI documentation.
mort96 17 hours ago [-]
What about it?
pjmlp 6 hours ago [-]
Your assertion.
mort96 3 hours ago [-]
I'm gonna need you to write full sentences because I still have exactly 0 clue what point you're making
pjmlp 1 hours ago [-]
Nah, you are on a trolling vibe.
All you need to do is clarify the first post on the thread with documentation.
Sometimes I do miss these Usenet like rounds.
vintagedave 19 hours ago [-]
And Delphi came along and used the same layout, so an interfaced Delphi object has beautiful COM interop.
pjmlp 19 hours ago [-]
Which is also used by C++ Builder.
In a tragic way, given the prevalence of COM in Windows, especially since Vista, someone at Microsoft should offer a few Delphi and C++ Builder licenses to the teams responsible for doing COM tooling.
Because MFC/OLE, ATL, WTL, WRL, C++/WinRT all have their sharp edges and could be so much better, if someone actually cared about productivity and framework ergonomics.
WalterBright 19 hours ago [-]
> 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.)
throwlifeaway 18 hours ago [-]
You mean... using a vtable? Are you claiming to have invented the concept of vtables?
WalterBright 14 hours ago [-]
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.
quotemstr 20 hours ago [-]
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.
pjmlp 19 hours ago [-]
Which shows how many devs never learnt about Windows development past Windows XP, given that COM is nowadays the main API delivery mechanism, as they redid Longhorn ideas in C++.
dblohm7 20 hours ago [-]
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.)
quotemstr 16 hours ago [-]
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.
rramadass 20 hours ago [-]
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.
18 hours ago [-]
pjmlp 19 hours ago [-]
COM is heavily used in Windows today, no need for past tense.
rramadass 18 hours ago [-]
Not directly by app developers. Everybody uses only WinRT/.NET based managed languages/runtimes/libraries/frameworks etc.
pjmlp 18 hours ago [-]
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.
rramadass 17 hours ago [-]
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.
pjmlp 17 hours ago [-]
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?
rramadass 9 hours ago [-]
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.
pjmlp 6 hours ago [-]
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.
rramadass 2 hours ago [-]
> All Windows APIs since Vista are delivered via COM.
Nope, This right here tells me you do not have much actual programming experience in Win32/Win64 apis nor of Windows Internals. The C-style windows apis are from kernel32/gdi32/user32/etc. user-mode dlls which call into intermediate ntdll/win32u dlls which then calls into kernel mode ntoskernel.exe/win32k.sys. With modern Windows there are another layer of abstractions with "Windows API Sets" (https://learn.microsoft.com/en-us/windows/win32/apiindex/win...) which decouple those user api from their actual implementation dlls.
COM is at user-mode and so interfaces to the first set of dlls only. Since the windows api breadth is vast not all of them are exposed via COM. WinRT uses/enhances classic COM but also calls Win32 api as needed. So Win32 api and WinRT api coexist with the latter providing the "modern" way to api access - https://en.wikipedia.org/wiki/Windows_Runtime But because WinRT is oriented towards secure sandboxed apps many low-level Win32 apis dealing with memory management, thread/process manipulations, system hooking etc. are limited/removed entirely from WinRT api.
Your claims must be backed up with references before asking others about their experience. I only see you name dropping and quoting historical data in all your comments which is not relevant to discussing/understanding anything.
rramadass 20 hours ago [-]
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.
Given OOP, the only ABI for an object is a vtable and that is left unspecified (for good reason) by the C++ standard.
COM said, "objects are cool and modules are cool so we need an ABI for objects" and specified a vtable. It isn't the only programming model which continued from the same observation: Python did too with its absolutely abysmal leaky PyObject ABI
pjmlp 20 hours ago [-]
SOM predates COM, and is even cooler, as it supported class inheritance, metaclasses and Smalltalk as target language.
On OS/2, Smalltalk enjoyed a role similar to what would be .NET and VB on Windows.
Sure you can use delegation with aggregation, and type libraries (nowadays .NET metadata), but still isn't as ergonomic.
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'm sorry for always asking questions. I've looked up a few documents, but since you clearly know much more about this than I do, I'm asking to study it myself as well. If it's too much trouble, feel free not to reply.
aw1621107 20 hours ago [-]
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].
Finally, C++11 tightened the specification for std::string viz. contiguous memory, some methods must have O(1) access time, when references/iterators/pointers can/cannot be invalidated etc. which doomed COW.
jdw64 18 hours ago [-]
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.
rramadass 2 hours ago [-]
I am glad that you found my comments useful. I use HN as my "blog" and generally include references to books/papers/articles as a pointer to further information on a topic. You will find links to lots of books if you search my comments for key phrases (eg. embedded, book etc.).
One thing i try to do is point people to lesser-known but very good and advanced books. I generally find that most HN book suggestions refer only to popular books most of which are just so-so while many great books remain unknown which is a shame. For example how many people know of Operating Systems in Depth by Thomas Doeppner? It has lots of helpful illustrations, compares concepts in both Linux/Windows implementations and is an all-round great book. I really understood the nuances of signal handling between kernel/user modes when i read it here.
jdw64 21 hours ago [-]
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 conventions established by compiler vendors.
jcranmer 21 hours ago [-]
No, ABI is not part of the C++ standard, although there are parts of C++ that do go "this is an ABI thing" (e.g., [[no_unique_address]]).
ABI is more of OS-level thing. Most systems these days follow the SysV ABI, which is largely defined by the hardware manufacturers via the processor-specific supplements (the x86-64 one is here: https://gitlab.com/x86-psABIs/x86-64-ABI). These largely delegate C++-specific conventions to the Itanium C++ ABI (which they likely directly reference), although the ARM ecosystem uses a somewhat different layout for the exception handling tables. Microsoft uses a different ABI for both the underlying C ABI and for the C++ compatibility layer built on top of the C ABI.
One of the issues that crops up is that vendors end up needing to add extensions to the ABI for various reasons, and these extensions tend to end up being incompatible, since they're added before they've had a time to be standardized. 16-bit floats is a particular historical bugbear, as is the C23 _BitInt stuff.
jdw64 21 hours ago [-]
Thank you for the kind comment. I'll make a note of it and look into it.
z_open 4 hours ago [-]
When the C++ standards committee make decisions crippling the language to preserve ABI (see std::regex), it's defacto part of the standard.
pjmlp 21 hours ago [-]
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 either use other systems languages, or expose their OS APIs in a different way, e.g. mainframes, micros, Android, ChromeOS, WebOS,...
Someone 18 hours ago [-]
> 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)
pjmlp 18 hours ago [-]
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.
mohamedkoubaa 21 hours ago [-]
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
bluGill 20 hours ago [-]
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.
uecker 16 hours ago [-]
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.
mohamedkoubaa 19 hours ago [-]
I would go far as to say that modern C++ is an Eldritch horror of a programming experience
pjmlp 19 hours ago [-]
Unfortunately no one is going to rewrite LLVM, GCC, CUDA, DirectX, Metal, SYSCL, V8,... into something else.
Same applies to C and UNIX/POSIX, OpenGL/Vulkan/OpenCL/NVN/LibGNM(X),...
Thus analysers and language subsetting tools, enforcing language style guides and safer coding practices.
rramadass 18 hours ago [-]
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.
mohamedkoubaa 17 hours ago [-]
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.
rramadass 8 hours ago [-]
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.
pjmlp 21 hours ago [-]
OS written the C, which is what many overlook.
If you are on e.g. z/OS you would be using ILE, Integrated Language Environment, on ChromeOS JS/WASM, on Android either DEX or JNI,...
bluGill 20 hours ago [-]
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::string (copy on write was banned - for good reason). They then watched the gcc community work through 10 years of pain to make the transition. They are also well aware that python 3 broke compatibility with Python 2 - and again it resulted in 10 years of pain for the python community to deal with that. With this history there are a lot of experts strongly against any breaking change. It might happen anyway, but only with strong justification and likely an attempt at a migration of some form (what? there are a lot of examples of migration plans that don't work that they are aware of)
Again, it is not because of convention, it is because of painful experience from those who break it.
MFHava 19 hours ago [-]
> 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...
Maxatar 16 hours ago [-]
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].
In the time since that VC++ has switched to a frozen ABI model that’s much closer to what Linux distros have. Each version of VC++ being ABI-incompatible and requiring each application to be built with a single version and ship its c++ runtime had some significant pros and cons.
Microsoft never said it outright, but I’ve always assumed the major con that made them switch was that people didn’t buy new Visual Studio versions because upgrading VS required also upgrading all of your binary blob closed-source dependencies.
andyg_blog 21 hours ago [-]
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.
Mond_ 21 hours ago [-]
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?
pjmlp 20 hours ago [-]
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.
jeffbee 20 hours ago [-]
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.
rramadass 19 hours ago [-]
This technique is often used for security-sensitive projects involving binary protection, obfuscation etc.
PS: James Coplien in his excellent Advanced C++ Programming Styles and Idioms shows many techniques one of which is actually replacing vtable entries at runtime to mimic features from more dynamical runtime languages (eg. Smalltalk).
mohamedkoubaa 21 hours ago [-]
C++ famously has no ABI, it is the implementations of C++ that have ABIs. The reason the situation is so bad is that it's considered explicitly out of scope of the language (it targets an abstract machine).
leni536 21 hours ago [-]
Neither of the ISO C and ISO C++ standards define an ABI.
mohamedkoubaa 21 hours ago [-]
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.
leni536 20 hours ago [-]
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.
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/OS, ClearPath MCP, OS 2200 and so forth.
And as a reminder, from a famous WG14 and WG21 member, and former Rust contributor,
"To Save C, We Must Save ABI"
https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-funct...
All you need to do is clarify the first post on the thread with documentation.
Sometimes I do miss these Usenet like rounds.
In a tragic way, given the prevalence of COM in Windows, especially since Vista, someone at Microsoft should offer a few Delphi and C++ Builder licenses to the teams responsible for doing COM tooling.
Because MFC/OLE, ATL, WTL, WRL, C++/WinRT all have their sharp edges and could be so much better, if someone actually cared about productivity and framework ergonomics.
Fun fact: Microsoft developed COM based on how Zortech C++ virtual functions worked. (It predated Microsoft C++ by years.)
(Though you cannot call just any method asynchronously; the interface's IDL needs specific annotations and the underlying object needs to implement ICallFactory.)
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.
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.
Regardless, WinRT is COM.
It only adds IInspectable as additional interface alongside IUnknown, and .NET metadata files instead of type libraries.
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.
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?
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.
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.
Nope, This right here tells me you do not have much actual programming experience in Win32/Win64 apis nor of Windows Internals. The C-style windows apis are from kernel32/gdi32/user32/etc. user-mode dlls which call into intermediate ntdll/win32u dlls which then calls into kernel mode ntoskernel.exe/win32k.sys. With modern Windows there are another layer of abstractions with "Windows API Sets" (https://learn.microsoft.com/en-us/windows/win32/apiindex/win...) which decouple those user api from their actual implementation dlls.
COM is at user-mode and so interfaces to the first set of dlls only. Since the windows api breadth is vast not all of them are exposed via COM. WinRT uses/enhances classic COM but also calls Win32 api as needed. So Win32 api and WinRT api coexist with the latter providing the "modern" way to api access - https://en.wikipedia.org/wiki/Windows_Runtime But because WinRT is oriented towards secure sandboxed apps many low-level Win32 apis dealing with memory management, thread/process manipulations, system hooking etc. are limited/removed entirely from WinRT api.
For your edification see this detailed older article; Turning to the past to power Windows’ future: An in-depth look at WinRT - https://arstechnica.com/features/2012/10/windows-8-and-winrt...
Your claims must be backed up with references before asking others about their experience. I only see you name dropping and quoting historical data in all your comments which is not relevant to discussing/understanding anything.
Here is an earlier comment of mine with some details - https://news.ycombinator.com/item?id=49142987
COM said, "objects are cool and modules are cool so we need an ABI for objects" and specified a vtable. It isn't the only programming model which continued from the same observation: Python did too with its absolutely abysmal leaky PyObject ABI
On OS/2, Smalltalk enjoyed a role similar to what would be .NET and VB on Windows.
Sure you can use delegation with aggregation, and type libraries (nowadays .NET metadata), but still isn't as ergonomic.
[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n26...
[1]: https://stackoverflow.com/q/12199710
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++? - https://www.linkedin.com/pulse/why-copy-on-write-cow-removed...
The std document on Concurrency Modifications to Basic String - https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n25...
Finally, C++11 tightened the specification for std::string viz. contiguous memory, some methods must have O(1) access time, when references/iterators/pointers can/cannot be invalidated etc. which doomed COW.
One thing i try to do is point people to lesser-known but very good and advanced books. I generally find that most HN book suggestions refer only to popular books most of which are just so-so while many great books remain unknown which is a shame. For example how many people know of Operating Systems in Depth by Thomas Doeppner? It has lots of helpful illustrations, compares concepts in both Linux/Windows implementations and is an all-round great book. I really understood the nuances of signal handling between kernel/user modes when i read it here.
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 conventions established by compiler vendors.
ABI is more of OS-level thing. Most systems these days follow the SysV ABI, which is largely defined by the hardware manufacturers via the processor-specific supplements (the x86-64 one is here: https://gitlab.com/x86-psABIs/x86-64-ABI). These largely delegate C++-specific conventions to the Itanium C++ ABI (which they likely directly reference), although the ARM ecosystem uses a somewhat different layout for the exception handling tables. Microsoft uses a different ABI for both the underlying C ABI and for the C++ compatibility layer built on top of the C ABI.
One of the issues that crops up is that vendors end up needing to add extensions to the ABI for various reasons, and these extensions tend to end up being incompatible, since they're added before they've had a time to be standardized. 16-bit floats is a particular historical bugbear, as is the C23 _BitInt stuff.
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 either use other systems languages, or expose their OS APIs in a different way, e.g. mainframes, micros, Android, ChromeOS, WebOS,...
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)
You're free to do whatever you feel like on your implementation, including not being compliant with the official language standard.
Same applies to C and UNIX/POSIX, OpenGL/Vulkan/OpenCL/NVN/LibGNM(X),...
Thus analysers and language subsetting tools, enforcing language style guides and safer coding practices.
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.
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.
If you are on e.g. z/OS you would be using ILE, Integrated Language Environment, on ChromeOS JS/WASM, on Android either DEX or JNI,...
The C++ standard did force gcc to break the ABI of std::string (copy on write was banned - for good reason). They then watched the gcc community work through 10 years of pain to make the transition. They are also well aware that python 3 broke compatibility with Python 2 - and again it resulted in 10 years of pain for the python community to deal with that. With this history there are a lot of experts strongly against any breaking change. It might happen anyway, but only with strong justification and likely an attempt at a migration of some form (what? there are a lot of examples of migration plans that don't work that they are aware of)
Again, it is not because of convention, it is because of painful experience from those who break it.
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...
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-...
Microsoft never said it outright, but I’ve always assumed the major con that made them switch was that people didn’t buy new Visual Studio versions because upgrading VS required also upgrading all of your binary blob closed-source dependencies.
Afaik Carbon is at this point the only attempt at a successor language that's still going?
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.
Program Obfuscation via ABI Debiasing (pdf) - https://www.google.com/goto?url=CAESYgHuR6pNsi8_4x_I2WBy7lmf...
PS: James Coplien in his excellent Advanced C++ Programming Styles and Idioms shows many techniques one of which is actually replacing vtable entries at runtime to mimic features from more dynamical runtime languages (eg. Smalltalk).