> How do you know that the Derived class hasn't been itself derived from
and the virtual method overridden again?

This is in the context of a slab heap. Allocate() has just been called,
which freshly constructed a new object of type Derived. Since I know the
object was just constructed as Derived, I am confident that the correct
class token is the one for Derived.

> Also, virtual destructors aren't constexpr. So unless you're violating
TheFirst Rule of Virtual (the destructor is virtual), your condition is a
constant false.

It is a requirement enforced via concept that the relevant types have no
non-trivial destructors (the context for this is a microkernel slab heap
for reference-counted objects), and so the default (constexpr) destructor
is used.

This seems valid to me given that known requirement, is it not?

> Though I don't see why you need virtuals if you're using CRTP, so maybe
those allocatable objects don't have virtuals and thus can be literals.

There is runtime polymorphism necessary (e.g. an "IsSignaled()" method with
varying implementation for like seven objects) which is invoked via
array-of-base-object-pointers and seems non-devirtualizable to me. I have
put substantial effort into devirtualization where possible, and there are
a number of cases where I do not believe I can devirtualize at runtime.

>Anyway, wouldn't it be better to have a static constexpr token getter
method that you can do if constexpr (requires {...}) on?

As I said, `I have thought about e.g. if constexpr (requires {
Derived::GetClassTokenStatic(); }),`

This works -- but it means that there is the potential for
GetClassTokenStatic() and GetClassToken() to disagree, which seems
undesirable particularly in the context of people less knowledgeable about
requirements than myself attempting to extend functionality with new
objects.

Of course, one solution to enforcing they agree would be to check if I can
constexpr-construct an instance and see that GetClassTokenStatic() matches
the token returned by the constexpr-instance if I can....but that is
fundamentally the same request I'm already making :)

On Sun, Oct 24, 2021 at 9:57 AM Thiago Macieira <thiago_at_[hidden]> wrote:

> On Saturday, 23 October 2021 12:57:55 PDT Michael Scire via Std-Proposals
> wrote:
> > if constexpr (is_constexpr_constructible_v<Derived>) {
> > constexpr ClassTokenType ClassToken = d{}.GetClassToken(); //
> > Valid if d is constexpr constructible and has constexpr virtual
> > implementation of GetClassToken().
> > obj->InitializeClassTokenCache(ClassToken); // This sets the
> > class token cache without having to perform a virtual call at runtime.
> > } else {
> > obj->InitializeClassTokenCache(obj->GetClassToken()); // This
> > performs a virtual call in the process of getting the class token.
> > }
>
> How do you know that the Derived class hasn't been itself derived from and
> the
> virtual method overridden again?
>
> class MyObject : public SlabAllocatable<MyObject, BaseObject> { /* ... */
> };
> class MyObject2 : public MyObject { /* ... */ };
>
> Also, virtual destructors aren't constexpr. So unless you're violating The
> First Rule of Virtual (the destructor is virtual), your condition is a
> constant false. Though I don't see why you need virtuals if you're using
> CRTP,
> so maybe those allocatable objects don't have virtuals and thus can be
> literals.
>
> Anyway, wouldn't it be better to have a static constexpr token getter
> method
> that you can do if constexpr (requires {...}) on?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DPG Cloud Engineering
>
>
>
>