c++ automatic factory registration of derived types

Question

Like many before me, I'm trying so get my derived types to automatically register with my factory. I read through many question and tried to focus on what I didn't find there.

I've got everything running nicely except the automatic registration.

My Goals:

1. automatically register any derived class of my base class Base
   1. only classes I mark as registrable
   2. not only direct sub-classes of Base
      • ex: Base -> Device -> Camera -> Webcam
      • this would make using the CRTP like described in this question dificult
2. minimal changes to the classes I want registered - dummies proof
3. would prefer using a registrator class than macros
   • like in this question, but I'm not sure if this is dependent on CRTP

What I have:

template <class T>
class abstract_factory
{
    public:
        template < typename Tsub > static void register_class();
        static T* create( const std::string& name );
    private:
        // allocator<T> is a helper class to create a pointer of correct type
        static std::map<std::string, boost::shared_ptr<allocator<T> > > s_map;
};

• templated abstract factory, with std::string as key type
• abstract factory has all members and methods static
• class name is recovered automatically with typeid (no need for text name when registering)
• registration by calling: abstract_factory<Base>::register_class<MyDerived>();

What I tried (or would like to but don't know how to properly):

• registrator<Derived> class: templateded class that is instantiated statically in Derived.cpp and should call abstract_factory::register_class<Derived>() in it's constructor
  • never gets called or instantiated
  • if I make an instance of Derived in main() this works -> kinda defeats the purpose though
• declare a simple static variable in each Derived.hpp and set it with the static registration method in Derived.cpp -> again, never gets called.
• make abstract_factory a true singleton instead of having everything static?

Could use any advice, large or small, thanx.

Bisect

Answer 1

I use a singleton with a member for registration, basically:

template< typename KeyType, typename ProductCreatorType >
class Factory
{
    typedef boost::unordered_map< KeyType, ProductCreatorType > CreatorMap;
    ...
};

Using Loki I then have something along these lines:

 typedef Loki::SingletonHolder< Factory< StringHash, boost::function< boost::shared_ptr< SomeBase >( const SomeSource& ) > >, Loki::CreateStatic > SomeFactory;

Registration is usually done using a macro such as:

#define REGISTER_SOME_FACTORY( type ) static bool BOOST_PP_CAT( type, __regged ) = SomeFactory::Instance().RegisterCreator( BOOST_PP_STRINGIZE( type ), boost::bind( &boost::make_shared< type >, _1 ) );

This setup has a number of advantages:

• Works with for example boost::shared_ptr<>.
• Does not require maintaining a huge file for all the registration needs.
• Is very flexible with the creator, anything goes pretty much.
• The macro covers the most common use case, while leaving the door open for alternatives.

Invoking the macro in the .cpp file is then enough to get the type registered at start up during static initialization. This works dandy save for when the type registration is a part of a static library, in which case it won't be included in your binary. The only solutions which compiles the registration as a part of the library which I've seen work is to have one huge file that does the registration explicitly as a part of some sort of initialization routine. Instead what I do nowadays is to have a client folder with my lib which the user includes as a part of the binary build.

From your list of requirements I believe this satisfies everything save for using a registrator class.

Rebarbative

Thanx for that :), I adapted your example and it works fine in with classes in my core library. What you pointed out about static libraries holds true for me, as most of my Derived classes are there. Do you know how to manage to export these symbols anyway? – Bisect

@Rebarbative Hi Ylisar, would you mind taking a look at my answer and telling me your opinion about it. I somehow feel something is wrong with it, but I can't name it. – Synovitis

@Yisar : can you please elaborate what you are doing in the macro for registration ? – Marybethmaryellen

Note that this won't work if you register your factories in translation units which are compiled into a static library. The linker can strip out the global variables because they are not ODR used anywhere. – Heartthrob

Answer 2

--- registration.h ---

#include <iostream>
#include <typeinfo>
#include <set>
#include <string>
using namespace std;

template<class T>
struct registrar {
        struct proxy { inline proxy();};
        static proxy p;
};

template<class T> typename registrar<T>::proxy registrar<T>::p;



struct factory {
        template <typename T> static T* create() {
               registrar<T>::p;
               return new T();
        }
};

set<string> & types();

template<typename T>
registrar<T>::proxy::proxy() { types().insert(typeid(T).name());}

--- registration.cpp ---

#include "registration.h"
#include <boost/foreach.hpp>

set<string> & types() {static set<string> types; return types;} 

int main() {
    BOOST_FOREACH(const string & s, types()) { cout<<s<<"\n";}
        factory::create<int>();
    factory::create<double>();
    factory::create<bool>();
        return 0;
}

--- registration_ext.cpp ---

#include "registration.h"

class myclass {};

void phony() {
    factory::create<double>();
    factory::create<myclass>();
}

Then compiled with:

$ g++ registration.cpp registration_ext.cpp -o registration

When run:

$ ./registration 
7myclass
b
d
i

So, it seems to have registered the classes before main is called.

Edit: I've noticed that this solution is implementation dependent. Under 3.6.2 the C++ standard says:

It is implementation-defined whether the dynamic initialization of a non-local variable with static storage duration is done before the first statement of main. If the initialization is deferred to some point in time after the first statement of main, it shall occur before the first odr-use (3.2) of any function or variable defined in the same translation unit as the variable to be initialized.

Synovitis

Thank you for that. It works well, unfortunetly, like Ylisar pointed out, such a mechanism fails with external linkage which is what I have. Cool code though :) – Bisect

@Alex Good point. This is getting interesting, I've modified my answer a bit now and it seems to work with external linkage as well. I believe this answer lies at the border of undefined behaviour land (probably inside it). I'd like to hear your opinion about it though. – Synovitis