When implementing a MessageFactory class to instatiate Message objects I used something like:
class MessageFactory
{
public:
static Message *create(int type)
{
switch(type) {
case PING_MSG:
return new PingMessage();
case PONG_MSG:
return new PongMessage();
....
}
}
This works ok but every time I add a new message I have to add a new XXX_MSG and modify the switch statement.
After some research I found a way to dynamically update the MessageFactory at compile time so I can add as many messages as I want without need to modify the MessageFactory itself. This allows for cleaner and easier to maintain code as I do not need to modify three different places to add/remove message classes:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <inttypes.h>
class Message
{
protected:
inline Message() {};
public:
inline virtual ~Message() { }
inline int getMessageType() const { return m_type; }
virtual void say() = 0;
protected:
uint16_t m_type;
};
template<int TYPE, typename IMPL>
class MessageTmpl: public Message
{
enum { _MESSAGE_ID = TYPE };
public:
static Message* Create() { return new IMPL(); }
static const uint16_t MESSAGE_ID; // for registration
protected:
MessageTmpl() { m_type = MESSAGE_ID; } //use parameter to instanciate template
};
typedef Message* (*t_pfFactory)();
class MessageFactory⋅
{
public:
static uint16_t Register(uint16_t msgid, t_pfFactory factoryMethod)
{
printf("Registering constructor for msg id %d\n", msgid);
m_List[msgid] = factoryMethod;
return msgid;
}
static Message *Create(uint16_t msgid)
{
return m_List[msgid]();
}
static t_pfFactory m_List[65536];
};
template <int TYPE, typename IMPL>
const uint16_t MessageTmpl<TYPE, IMPL >::MESSAGE_ID = MessageFactory::Register(
MessageTmpl<TYPE, IMPL >::_MESSAGE_ID, &MessageTmpl<TYPE, IMPL >::Create);
class PingMessage: public MessageTmpl < 10, PingMessage >
{⋅
public:
PingMessage() {}
virtual void say() { printf("Ping\n"); }
};
class PongMessage: public MessageTmpl < 11, PongMessage >
{⋅
public:
PongMessage() {}
virtual void say() { printf("Pong\n"); }
};
t_pfFactory MessageFactory::m_List[65536];
int main(int argc, char **argv)
{
Message *msg1;
Message *msg2;
msg1 = MessageFactory::Create(10);
msg1->say();
msg2 = MessageFactory::Create(11);
msg2->say();
delete msg1;
delete msg2;
return 0;
}
The template here does the magic by registering into the MessageFactory class, all new Message classes (e.g. PingMessage and PongMessage) that subclass from MessageTmpl.
This works great and simplifies code maintenance but I still have some questions about this technique:
-
Is this a known technique/pattern? what is the name? I want to search more info
about it. -
I want to make the array for storing new constructors MessageFactory::m_List[65536]
a std::map but doing so causes the program to segfault even before reaching main().
Creating an array of 65536 elements is overkill but I have not found a way to
make this a dynamic container. -
For all message classes that are subclasses of MessageTmpl I have to implement
the constructor. If not it won’t register in the MessageFactory.For example commenting the constructor of the PongMessage:
class PongMessage: public MessageTmpl < 11, PongMessage > { public: //PongMessage() {} /* HERE */ virtual void say() { printf("Pong\n"); } };would result in the PongMessage class not being registered by the MessageFactory and the
program would segfault in the MessageFactory::Create(11) line. The question is
why the class won’t register? Having to add the empty implementation of the 100+
messages I need feels inefficient and unnecessary.
Answer One
The general technique of deriving a class like this is the Curiously Recurring Template Pattern (CRTP):
Your specific technique of using a template class’s static member initialization to register subclasses of that class is (IMO) simply brilliant, and I’ve never seen that before. A more common approach, used by unit test frameworks like UnitTest++ and Google Test, is to provide macros that declare both a class and a separate static variable initializing that class.
Answer Two
Static variables are initialized in the order listed. If you move your m_List declaration before your MessageFactory::Register calls, you should be safe. Also keep in mind that if you start declaring Message subclasses in more than one file, you’ll have to wrap m_List as a singleton and check that it’s initialized before each use, due to the C++ static initialization order fiasco.
Answer Three
C++ compilers will only instantiate template members that are actually used. Static members of template classes is not an area of C++ that I’ve used much, so I could be wrong here, but it looks like providing the constructor is enough to make the compiler think that MESSAGE_ID is used (thus ensuring that MessageFactory::Register is called).
This seems very unintuitive to me, so it may be a compiler bug. (I was testing this in g++ 4.3.2; I’m curious to know how Comeau C++, for example, handles it.)
Explicitly instantiating MESSAGE_ID also suffices, at least in g++ 4.3.2:
But that’s even more unnecessary work than providing an empty default constructor.
I can’t think of a good solution using your current approach; I’d personally be tempted to switch to a technique (such as macros or using a script to generate part of your source files) that relied less on advanced C++. (A script would have the added advantage of easing maintenance of MESSAGE_IDs.)
In response to your comments:
Singletons are generally to be avoided because they’re often overused as poorly disguised global variables. There are a few times, however, when you really do need a global variable, and a global registry of available Message subclasses is one of those times.
Yes, the code that you provided is initializing MESSAGE_ID, but I was talking about explicitly instantiating each subclass’s instance of MESSAGE_ID. Explicit instantiation refers to instructing the compiler to instantiate a template even if it thinks that that template instance won’t otherwise be used.
I suspect that the static function with the volatile assignment is there to trick or force the compiler into generating the MESSAGE_ID assignment (to get around the problems that dash-tom-bang and I pointed out with the compiler or linker dropping or not instantiating the assignment).