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!

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Oliver Hunt via Std-Proposals
Sent: Monday, June 2, 2025 4:53 AM
To: std-proposals_at_lists.isocpp.org
Cc: Oliver Hunt <oliver_at_apple.com>
Subject: Re: [std-proposals] Standard support for different ABI's for class vtables



> On Jun 1, 2025, at 7:34 PM, Thiago Macieira via Std-Proposals <std-proposals_at_lists.isocpp.org> wrote:
>
> On Sunday, 1 June 2025 18:42:34 Brasilia Standard Time Oliver Hunt via
> Std- Proposals wrote:
>> The fact is that the windows C++ ABI is not the same as other
>> platforms, and that’s what compilers targeting windows should be
>> using. Arguing otherwise is no different from saying “long double on
>> x86-64 darwin (maybe linux, I’m not sure?) is fp80, so compilers
>> should be able to use that abi on windows despite it not being the
>> case”/
> [cut]
>> In an ideal world compilers would emit code that conforms the the
>> platform ABI, rather than complaining that what is fundamentally
>> incorrect codegen not working.
>
> The platform ABI does not include C++. The processor-specific ABI
> (psABI) for each OS only covers calling sequence and standard types.
> The C++ ABI comes on top and it has a psABI portion for some low-level details.

By definition the *platform* defines the C++ ABI. It does not matter if there is another specification for what the ABI should look like, if the platform says “this is the ABI for calling a polymorphic function” that is the ABI for calling a polymorphic function. What you are trying to say is “if a platform provides a C++ interface, and that interface does not conform to an ABI definition that postdates the platform, the platform is wrong”. That’s nonsense. Again, the C++ spec does not say anything about vtables, and the documents you are referring to are, if anything, recommendations. If those documents do not match the platform’s ABI, you don’t get to then claim that your following of those recommendations trumps the ABI provided by the OS.

Literally the entire problem here can be summed up with “some compilers have decided that their preferred ABI is more important than the ABI defined by the host OS, and now people are acting like it is the OS’s fault for not supporting codegen that is not conforming to the host platform’s ABI”.

Again, the processor vendor does not define the ABI, the OS does. The processor vendor may make recommendations, but if those recommendations don’t match the OS, it is the job of the compiler to match the ABI presented by the OS.

This utter utter nonsense of “clang/gcc emits code but the OS is wrong so the code breaks” needs to stop.

It is the job of the compiler to ensure that the code it generates conforms to the ABI of the host platform. Not some idealized or preferred ABI. The host OS *cannot* change its ABI, the compiler can fix its codegen bugs.

Please note, I’m not saying the ABI presented by MSVC is “good”, and there are parts I’m sure people at MS would like to change, but they can’t.

The reality is that the ABI for C++ polymorphism on windows is not that same as that on other platforms, and that cannot change. To argue otherwise is to sit on the beach telling the tide not to come in.

—Oliiver
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals