On Tuesday, 23 January 2024 12:59:02 PST Thiago Macieira via Std-Proposals
wrote:
> So you're saying it should basically emit a larger structure with a magic up
> front, where the type info is a sub-object. That way, it is possible to
> scan backwards to find out if it part of such a sub-object and thus whether
> more information is present.

Actually, there are simpler solutions for this.

First, abi::__vmi_class_type_info is itself a polymorphic type. If we added an
abi::__vmi_class_type_info2, the distinction could be made by the typeinfo's
typeinfo itself.

    void const *get_polymorphic_facilitator(type_info const &ti)
    {
        auto ti2 = dynamic_cast<abi::__vmi_class_type_info2 *>(&ti);
        return t2 ? t2->vtable : nullptr;
    }

Second, even that is not necessary, because __vmi_class_type_info has a flags
field, so the ABI could dedicate another bit to indicating whether this one has
the extra field at the end.

That said, neither of those eliminate the first two problems I listed:

> 1) I still don't see why we should bother. There's no use-case for going
> from the type_info to the vtable.
>
> 2) get_polymorphic_facilitator() can fail, as you've shown. That means the
> functionality you build on top of it must also be allowed to fail, and I
> don't think you want that.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering