Static member initialization using CRTP in separate library

Question

After digging the web, I found some reference to a powerful pattern which exploits CRTP to allow instantiation at run-time of static members:

C++: Compiling unused classes

Initialization class for other classes - C++

And so on. The proposed approach works well, unless such class hierarchy is placed into an external library. Doing so, run-time initialization no more works, unless I manually #include somewhere the header file of derived classes. However, this defeats my main purpose - having the change to add new commands to my application without the need of changing other source files.

Some code, hoping it helps:

class CAction
{
protected:
    // some non relevant stuff
public:
    // some other public API
    CAction(void) {}
    virtual ~CAction(void) {}

    virtual std::wstring Name() const = 0;
};

template <class TAction>
class CCRTPAction : public CAction
{
public:
    static bool m_bForceRegistration;
    CCRTPAction(void) { m_bForceRegistration; }
    ~CCRTPAction(void) { }

    static bool init() {
        CActionManager::Instance()->Add(std::shared_ptr<CAction>(new TAction));
        return true;
    }
};

template<class TAction> bool CCRTPAction<TAction>::m_bForceRegistration = CCRTPAction<TAction>::init();

Implementations being done this way:

class CDummyAction : public CCRTPAction<CDummyAction>
{
public:
    CDummyAction() { }
    ~CDummyAction() { }
    std::wstring Name() const { return L"Dummy"; }
};

Finally, here is the container class API:

class CActionManager
{
private:
    CActionManager(void);
    ~CActionManager(void);
    std::vector<std::shared_ptr<CAction>> m_vActions;   
    static CActionManager* instance;
public:
    void Add(std::shared_ptr<CAction>& Action);
    const std::vector<std::shared_ptr<CAction>>& AvailableActions() const;
    static CActionManager* Instance() {
        if (nullptr == instance) {
            instance = new CActionManager();
        }
        return instance;
    }
};

Everything works fine in a single project solution. However, if I place the above code in a separate .lib, the magic somehow breaks and the implementation classes (DummyAction and so on) are no longer instantiated.

I see that #include "DummyAction.h" somewhere, either in my library or in the main project makes things work, but

1. For our project, it is mandatory that adding Actions does not require changes in other files.
2. I don't really understand what's happening behind the scene, and this makes me uncomfortable. I really hate depending on solutions I don't fully master, since a bug could get out anywhere, anytime, possibly one day before shipping our software to the customer :)
3. Even stranger, putting the #include directive but not defining constructor/destructor in the header file still breaks the magic.

Thanks all for attention. I really hope someone is able to shed some light...

Answer 1

I can describe the cause of the problem; unfortunately I can't offer a solution.

The problem is that initialisation of a variable with static storage duration may be deferred until any time before the first use of something defined in the same translation unit. If your program never uses anything in the same translation unit as CCRTPAction<CDummyAction>::m_bForceRegistration, then that variable may never be initialised.

As you found, including the header in the translation unit that defines main will force it to be initialised at some point before the start of main; but of course that solution won't meet your first requirement. My usual solution to the problems of initialising static data across multiple translation units is to avoid static data altogether (and the Singleton anti-pattern doubly so, although that's the least of your problems here).

Answer 2

As explained in Mike's answer, the compiler determines that the static member CCRTPAction<CDummyAction>::m_bForceRegistration is never used, and therefore does not need to be initialised.

The problem you're trying to solve is to initialise a set of 'plugin' modules without having to #include their code in a central location. CTRP and templates will not help you here. I'm not aware of a (portable) way in C++ to generate code to initialise a set of plugin modules that are not referenced from main().

If you're willing to make the (reasonable) concession of having to list the plugin modules in a central location (without including their headers), there's a simple solution. I believe this is one of those extremely rare cases where a function-scope extern declaration is useful. You may consider this a dirty hack, but when there's no other way, a dirty hack becomes an elegant solution ;).

This code compiles to the main executable:

core/module.h

template<void (*init)()>
struct Module
{
    Module()
    {
        init();
    }
};

// generates: extern void initDummy(); Module<initDummy> DummyInstance
#define MODULE_INSTANCE(name) \
    extern void init ## name(); \
    Module<init ## name> name ## Instance

core/action.h

struct Action // an abstract action
{
};

void addAction(Action& action); // adds the abstract action to a list

main.cpp

#include "core/module.h"

int main()
{
    MODULE_INSTANCE(Dummy);
}

This code implements the Dummy module and compiles to a separate library:

dummy/action.h

#include "core/action.h"

struct DummyAction : Action // a concrete action
{
};

dummy/init.cpp

#include "action.h"

void initDummy()
{
    addAction(*new DummyAction());
}

If you wanted to go further (this part is not portable) you could write a separate program to generate a list of MODULE_INSTANCE calls, one for each module in your application, and output a generated header file:

generated/init.h

#include "core/module.h"

#define MODULE_INSTANCES \
    MODULE_INSTANCE(Module1); \
    MODULE_INSTANCE(Module2); \
    MODULE_INSTANCE(Module3);

Add this as a pre-build step, and core/main.cpp becomes:

#include "generated/init.h"

int main()
{
    MODULE_INSTANCES
}

If you later decide to load some or all of these modules dynamically, you can use exactly the same pattern to dynamically load, initialise and unload a dll. Please note that the following example is windows-specific, untested and does not handle errors:

core/dynamicmodule.h

struct DynamicModule
{
    HMODULE dll;

    DynamicModule(const char* filename, const char* init)
    {
        dll = LoadLibrary(filename);
        FARPROC function = GetProcAddress(dll, init);
        function();
    }
    ~DynamicModule()
    {
        FreeLibrary(dll);
    }
};

#define DYNAMICMODULE_INSTANCE(name) \
    DynamicModule name ## Instance = DynamicModule(#name ".dll", "init" #name)

Answer 3

As Mike Seymour stated the static template stuff will not give you the dynamic loading facilities you want. You could load your modules dynamically as plug ins. Put dlls containing an action each into the working directory of the application and load these dlls dynamically at run-time. This way you will not have to change your source code in order to use different or new implementations of CAction.

Some frameworks make it easy to load custom plug ins, for example Qt.