Automatic static invocation of derived types

Question

Does anyone know of a way to make derived classes automatically instantiate a static variable with a template type (this either has to require nothing from the writer of the der

Answer 1

You might be able to get what you want using a mix-in and the CRTP.

But first, you need to take care of the "order of initialization" problem. To ensure the gFactory exists before you try to use it, you really need to make it a proper "singleton" class, like this:

class Factory {
public:
    static Factory &getFactory() { static Factory f; return f; }
    template 
    void registerEntityType() { ... }
};

Then the "mix-in" would look like this:

template 
class EntityMixin {
private:
    struct RegisterMe {
        RegisterMe() { Factory::getFactory().registerEntityType(); }
    };
    EntityMixin() {
        static RegisterMe r;
    }
};

And you would use it like this:

class EntityType1 : public Entity, EntityMixin { ... };
class EntityType2 : public Entity, EntityMixin { ... };
class EntityType3 : public Entity, EntityMixin { ... };

[Update]

You can also take the Xeo/Merlyn idea of creating an EntityBase, rename EntityMixin to Entity, and avoid the need to inherit from two places. I actually think my original proposal is more clear; you could even call the mixin FactoryMixin and tack it on to any class you want to register.

But the Xeo/Merlyn version would look like so:

class Factory {
    public:
    static Factory &getFactory() { static Factory f; return f; }
    template 
    void registerEntityType() { ... }
};

class EntityBase { ... } ;

template 
class Entity : public EntityBase {
private:
    struct RegisterMe {
        RegisterMe() { Factory::getFactory().registerEntityType(); }
    };
    Entity() {
        static RegisterMe r;
    }
};

class EntityType1 : public Entity { ... };
class EntityType2 : public Entity { ... };
class EntityType3 : public Entity { ... };

The keys to any solution are the CRTP and careful use of static local variables to avoid the order-of-initialization problem.