>  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@macieira.org> 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