C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Standard support for different ABI's for class vtables

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Mon, 2 Jun 2025 08:34:18 +0200
I think there are exceptions:   You need an ABI to call (operating) system libraries and system calls You need the OS-specific or -accepted line endings to pass strings with line endings to system calls. (E.g. printing out to the console). A primitive system could limit the preserved registers during interrupts.   You could at the same time use other non-OS-ABIs to call non-OS-"modules"   -----Ursprüngliche Nachricht----- Von:Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 02.06.2025 08:10 Betreff:Re: [std-proposals] Standard support for different ABI‘s for class vtables An:std-proposals_at_[hidden]; CC:Tiago Freire <tmiguelf_at_[hidden]>; I think there's a problem with actually understanding the problem. And ABI is not an "operating system" thing. IT ISN'T! There's nothing right now that would stop a compiler from generating code with a different ABI and have it work, no matter which OS you are talking about. It's only important that your ABI be a certain way when you are interacting with other modules that you haven't written/compiled yourself and that already existed as utilities for that OS. If you want to communicate with code that already exists you need to be able to talk its language. But if you are not, you don't have too, and there's nothing that stops the OS from providing libraries that "speak different languages". You don't want to do that for ease of maintainability, but you can do it. It's like the line ending thing "CRNL" or "NL", also not an OS thing, at least not anymore, it's a choice of editor problem now, and even so not even that. And we have already ways to "manipulate" the ABI in a way, in the form of annotations for calling conventions (not portable as they might be), could be extended to classes as a way to implement such a feature if you really wanted to. But the question is, why would you want it too? Again, the standard doesn't know what a dll is, external code is not a thing that it is prepared to tackle at this point (unless there is a comprehensive work group). Ok carry on!

Received on 2025-06-02 06:42:17