Live data from Hacker News

Thoroughly Understanding C++ ABI (2024)

ykiko.me

71–79 of 79 posts

Re: Thoroughly Understanding C++ ABI (2024)

#71
post #65

Earlier quoted context omitted.

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.

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

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.

Re: Thoroughly Understanding C++ ABI (2024)

#72
post #44

Earlier quoted context omitted.

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.

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.

Re: Thoroughly Understanding C++ ABI (2024)

#74
post #69
post #67

Earlier quoted context omitted.

Your assertion.

I'm gonna need you to write full sentences because I still have exactly 0 clue what point you're making

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.

Re: Thoroughly Understanding C++ ABI (2024)

#75
post #74
post #69

Earlier quoted context omitted.

I'm gonna need you to write full sentences because I still have exactly 0 clue what point you're making

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.

I genuinely did not understand that you were asking for documentation.

I believe GNU follows the SysV ABI on amd64: https://refspecs.linuxfoundation.org/elf/x86_64-abi-0.95.pdf

Re: Thoroughly Understanding C++ ABI (2024)

#76
post #17

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

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

Android is Linux and it's written in C. Bionic is still a posix libc.

Re: Thoroughly Understanding C++ ABI (2024)

#77
post #9
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, 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 convent…

One more addition.

There is often a distinction made between "language ABI" and "library ABI" in documentation which is highly confusing.

The answer is: library API + compiler ABI = library ABI

GNU libstdc++ ABI Policy and Guidelines - https://gcc.gnu.org/onlinedocs/gcc-9.2.0/libstdc++/manual/ma...

Re: Thoroughly Understanding C++ ABI (2024)

#78

Earlier quoted context omitted.

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.

AFAIK, the first design for implementation of vtables was by Bjarne Stroustrup in his paper Multiple Inheritance for C++ in 1986/1987.

Pdf at https://www.google.com/goto?url=CAESawHuR6pN4SDa5tLkqrSuoaot... and reissue at https://www.researchgate.net/publication/2396782_Multiple_In...

I read this in one of the documentation books (still have it somewhere) which came with SCO Unix (don't recall the date). This book contained articles on C++ only and was an introduction to the language and compiler (since the language was very new). I also remember that it had an article on Template mechanism.

Next was Jan Gray from Microsoft's excellent 1994 article in MSDN titled C++: Under the Hood which explained class layouts/vtables/etc. It is still a excellent read today. Pdf at https://www.google.com/goto?url=CAESewHuR6pNy2XLp9fzgwckhWpg...

Finally of course you have Inside the C++ Object Model by Stanley Lippman explaining everything in detail.

Re: Thoroughly Understanding C++ ABI (2024)

#79

Earlier quoted context omitted.

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

I would encourage programmers to learn c++ because it's important, but I'll never lie about what it's like to actually use it
Post reply on HN