dynamic_cast structures are only included for types with a vtable.

On Thu, Apr 11, 2024 at 2:10 PM Mihail Mihaylov via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I'm not talking so much about how the changes to `any` could or should be
> implemented. I wanted to discuss the potential usefulness of the proposed
> changes to `any`. For the record, I don't endorse the proposed changes to
> `type_info` either and I think that the OP really wants the `any` changes,
> that's what should be proposed and discussed.
>
> On Thu, Apr 11, 2024 at 3:21 PM Gašper Ažman <gasper.azman_at_[hidden]>
> wrote:
>
>> std::any type-erases the copy ctor and the dtor of the encapsulated type.
>> It does that on assignment, and codegens that bit of the rtti needed to
>> recover with get.
>>
>> all you need is some way to get a typelist of bases and you can codegen
>> the code, on assignment. You *already* have to do that in a compilation
>> unit where the full definition of the stored class is available. You can
>> ask for it in a compilation unit where only a forward-decl is available,
>> and that's alright, you'll be going through an extern template that you
>> generated in the other compilation unit.
>>
>> It's really not difficult if you've ever done your own type-erasure.
>>
>
> So, basically you are proposing a table of upcast functions which is
> generated at compile-time at the assignment site and associated with the
> `any` instance. Then the cast function can look for the target type in the
> table and execute the upcast function. (Or a single function with a
> switch-case statement could be generated).
>
> Yes, this will work. But it seems to me that these tables will duplicate
> information that's already available in the runtime to support dynamic_cast
> and can allow the cast to be implemented without changing either
> `type_info` or `any`.
>
>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.--
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>