Date: Sun, 01 Jun 2025 14:42:34 -0700
> On Jun 1, 2025, at 9:01 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Sun, Jun 1, 2025 at 12:46 AM Frederick Virchanza Gotham wrote:
>>
>>
>> I've been saying for a while now that C++ is held back by Microsoft's implementation of polymorphism; I posted the following here 6 months ago:
>>
>> https://lists.isocpp.org/std-proposals/2024/11/11541.phpp
>
>
> The link I gave above is broken, here's the correct one:
> https://lists.isocpp.org/std-proposals/2024/11/11541.php
>
> I've been thinking about a way to accommodate the problem of the
> Microsoft compiler sometimes not putting the vtable pointer at the
> beginning of the object, and the consequences that this has for the
> entire worldwide C++ community. The two consequences are:
>
> (1) Cannot use dynamic_cast on a void* to get the most derived object
You cannot do that safely in pointer authenticated environments either.
Clang disallows it, and I think GCC does as well - on all architectures.
The fact the msvc does not put a vtable pointer where you think it should go is also irrelevant, as the specification makes no mention of vtable pointers, and an implementation does not need to use them to implement C++ polymorphism.
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”/
> So in an ideal world, Microsoft would change its ABI.
That’s not how ABIs work, you don’t get to change them, especially not an ABI that has been in place for decades. So claiming “MS should break three decades of software to satisfy people who refuse to acknowledge the ABI difference” is so far from “ideal” I cannot image why you would write that sentence.
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.
—Oliver
>
> On Sun, Jun 1, 2025 at 12:46 AM Frederick Virchanza Gotham wrote:
>>
>>
>> I've been saying for a while now that C++ is held back by Microsoft's implementation of polymorphism; I posted the following here 6 months ago:
>>
>> https://lists.isocpp.org/std-proposals/2024/11/11541.phpp
>
>
> The link I gave above is broken, here's the correct one:
> https://lists.isocpp.org/std-proposals/2024/11/11541.php
>
> I've been thinking about a way to accommodate the problem of the
> Microsoft compiler sometimes not putting the vtable pointer at the
> beginning of the object, and the consequences that this has for the
> entire worldwide C++ community. The two consequences are:
>
> (1) Cannot use dynamic_cast on a void* to get the most derived object
You cannot do that safely in pointer authenticated environments either.
Clang disallows it, and I think GCC does as well - on all architectures.
The fact the msvc does not put a vtable pointer where you think it should go is also irrelevant, as the specification makes no mention of vtable pointers, and an implementation does not need to use them to implement C++ polymorphism.
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”/
> So in an ideal world, Microsoft would change its ABI.
That’s not how ABIs work, you don’t get to change them, especially not an ABI that has been in place for decades. So claiming “MS should break three decades of software to satisfy people who refuse to acknowledge the ABI difference” is so far from “ideal” I cannot image why you would write that sentence.
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.
—Oliver
Received on 2025-06-01 21:42:50