Date: Wed, 17 Jan 2024 20:04:42 -0800
On Wednesday, 17 January 2024 05:39:14 PST Frederick Virchanza Gotham via Std-
Proposals wrote:
> So in order to get all of this working, the following two changes
> would be required to the standard:
>
> CHANGE 1: The type 'std::type_info' needs a new consteval static
> member function called 'get_polymorphic_facilitator' which returns a
> pointer to the class's vtable. (It returns a nullptr is
> !std::is_polymorphic_v<T>). The C++ Standard won't need to mention the
> word 'vtable', it can just say "polymorphic facilitator" and leave its
> implementation as unspecified.
>
> CHANGE 2: The standard library needs a new standalone constexpr
> function called 'std::devirtualise' which changes a 'virtual' pointer
> to a 'direct' pointer, which on GNU g++ would be implemented something
> like:
Change 1 can be skipped if the devirtualize function takes a pointer to the
object whose vtable you want to read. That's important because Change 1 is not
implementable, as none of the type_info objects today have a link back to the
vtable, and such a link cannot be added without an ABI incompatibility.
The library function will likely be implemented as an intrinsic, because the
compiler knows where in the object the vtable pointer is located.
Proposals wrote:
> So in order to get all of this working, the following two changes
> would be required to the standard:
>
> CHANGE 1: The type 'std::type_info' needs a new consteval static
> member function called 'get_polymorphic_facilitator' which returns a
> pointer to the class's vtable. (It returns a nullptr is
> !std::is_polymorphic_v<T>). The C++ Standard won't need to mention the
> word 'vtable', it can just say "polymorphic facilitator" and leave its
> implementation as unspecified.
>
> CHANGE 2: The standard library needs a new standalone constexpr
> function called 'std::devirtualise' which changes a 'virtual' pointer
> to a 'direct' pointer, which on GNU g++ would be implemented something
> like:
Change 1 can be skipped if the devirtualize function takes a pointer to the
object whose vtable you want to read. That's important because Change 1 is not
implementable, as none of the type_info objects today have a link back to the
vtable, and such a link cannot be added without an ABI incompatibility.
The library function will likely be implemented as an intrinsic, because the
compiler knows where in the object the vtable pointer is located.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2024-01-18 04:04:44