ich habe in letzter Zeit ein (vermutlich?) von mir erdachtes pattern für message systems in c++ angewandt, das ich hier mal vorstellen wollte (ich hoffe natürlich auch auf feedback/Verbesserungsvorschläge).
Es geht, wie der Titel schon sagt, um ein message system in c++ zur Kommunikation zwischen Objekten. Um zu zeigen, was ich unter "message system" verstehe, erst der klassische Ansatz:
Es gibt eine Basisklasse "Listener", die bestimmte virtuelle Funktionen bereitstellt, in etwa so (ein fiktives Beispiel für einen Listener auf Mausinput Events):

class MouseListener
{
public:
    virtual void leftButtonDown( unsigned int XPos , unsigned int YPos ) {}
    virtual void rightButtonDown( unsigned int XPos , unsigned int YPos ) {}
    virtual void leftButtonUp( unsigned int XPos , unsigned int YPos ) {}
    //...
};

Ein Klasse kann dann von diesem Listener erben und die jeweiligen Funktionen überschreiben:

class MyListener
    : public MouseListener
{
public:
    void leftButtonDown( unsigned int XPos , unsigned int YPos ) { /* irgendetwas sinnvolles tun */ }
};

Dann kann man einen MyListener dem MouseInput übergeben, der MouseInput an jeden MouseListener verteilt:

MouseInput mouse_input;

int main()
{
    MyListener listener;
    mouse_input.addListener( listener );
}

Dieses pattern funktioniert auch fast immer. Ich finde es aber nicht ganz optimal: Angenommen, man will einen MouseListener, der alle ButtonDown - Events mitzählt, unabhängig von der Taste. Man müsste jetzt jede "...ButtonDown" - Methode überschrieben, nur um jedes Mal exakt den gleichen code auszuführen. Das ist zweifelsohne möglich, aber was passiert, wenn man während der Entwicklung auf die Idee kommt, auch andere Tasten zu unterstützen? Man müsste dem MouseListener-Interface eine neue Funktion hinzufügen, etwa "middleButtonDown". Dann müsste man in jeder Klasse, die von MouseListener erbt, prüfen, ob der code so noch funktioniert (was er im Fall des Klick-Counters nicht tut), was leicht zu bugs führen kann.
Wenn man sich jetzt auch noch vorstellt, dass man das Gleiche mit einem KeyboardListener machen müsste, der Methoden wie "AKeyDown" bereitstellt, läuft es vermutlich jedem von uns kalt den Rücken runter.

Die Lösung ist Vererbung. Man könnte eine Basis-Message für "ButtonDown" - Events erstellen, von der dann alle "...ButtonDown" - Events erben, etwa so:

struct ButtonDown
{
    unsigned int XPos;
    unsigned int YPos;
};

struct LeftButtonDown
    : public ButtonDown
{
};

struct RightButtonDown
	: public ButtonDown
{
};

Der Weg vom abstrakten Listener zum eigentlich Handler ist aber alles andere als offensichtlich (zumindest war er das nicht für mich).
Zuerst muss durch virtual Functions jede Message auf die Ebene des Handlers kommen. Danach muss noch irgendwie statt der 1:1 virtual Function calls die normale overload resolution verwendet werden.

Jetzt aber zuerst die Listener - Klasse:

template< class ...AllMessageTypes >
class Listener;

template<>
class Listener<>
{
private:
    struct MessageDummy;
public:
    void listen( const MessageDummy & );
    //von dieser Klasse wird abgeleitet, um das Listener< ... > - Interface zu benutzen
    template< class HandlerType > //HandlerType ist der Typ der Klasse, die von Handler ableitet
    class Handler;
};

template< class Head , class ...Tail >
class Listener< Head , Tail... >
    : public Listener< Tail... >
{
public:
    virtual void listen( const Head & ) = 0;
    using Listener< Tail... >::listen;
    template< class HandlerType >
    class Handler;
};

So weit so einfach. Jetzt kommt der schwierigere Teil: Wir müssen zum einen alle rein virtuellen Funktionen überschrieben, andererseits müssen wir immernoch irgendwie Funktionsüberladung verwenden. Ersteres ist wieder mit variadic templates möglich, für den zweiten Teil werden wir SFINAE (-> http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error ) verwenden.

Zur Verwendung von SFINAE:

template< class >
class VoidWrapper
{
public:
    typedef void Void;
};

template< class HandlerType , class MessageType >
auto handleIfPossible( HandlerType *Handler , const MessageType *Message ) -> typename VoidWrapper< decltype( Handler->handle( *Message ) ) >::Void
//Fehler, wenn Handler->handle( *Message ) nicht möglich ist
{
   Handler->handle( *Message );
};

template< class HandlerType , class MessageType >
void handleIfPossible( ... )
//schwächer als die andere Version, wegen Ellipse
{
}

Jetzt kommen wir zur Verwendung von varidadic templates zum Überschreiben der "listen"-Funktionen

template< class ... >
class TypeList;

template< class HandlerType , class StaticListOfAllMessages , class IterationListOfAllMessages >
class ListenOverwriter;

template< class HandlerType , class ...AllMessageTypes >
class ListenOverwriter< HandlerType , TypeList< AllMessageTypes... > , TypeList<> >
    : public Listener< AllMessageTypes... >
{
protected:
    HandlerType *handler;
};

template< class HandlerType , class SetOfAllMessages , class Head , class ...Tail >
class ListenOverwriter< HandlerType , SetOfAllMessages , TypeList< Head , Tail... > >
    : public ListenOverwriter< HandlerType , SetOfAllMessages , TypeList< Tail... > >
{
protected:
    using ListenOverwriter< HandlerType , SetOfAllMessages , TypeList< Tail... > >::handler;
    void listen( const Head &Message )
    {
        handleIfPossible< HandlerType , Head >( handler , &Message );
    }
};

//Eigentlich müsste man auch noch für den Fall bei keiner Message Handler definieren. Das lasse ich der Einfachheit halber jetzt weg
template< class HeadMessageType , class ...Tail > template< class HandlerType >
class Listener< HeadMessageType , Tail... >::Handler
	: public ListenOverwriter< HandlerType , TypeList< HeadMessageType , Tail... > , TypeList< HeadMessageType , Tail... > >
{
private:
	using ListenOverwriter< HandlerType , TypeList< HeadMessageType , Tail... > , TypeList< HeadMessageType , Tail... > >::handler;
public:
	Handler( HandlerType &HandlingObject )
	{
		handler = &HandlingObject;
	}
};

Das wars auch schon!
Verwendet werden kann dieses System nun so (ich verwende wieder die Message von weiter oben):

typedef Listener< ButtonDown , LeftButtonDown , RightButtonDown > MouseListener;

template< class HandlingType >
class MouseHandler
    : public MouseListener::Handler< HandlingType >
{
public:
    MouseHandler( HandlingType &HandlingObject )
        : MouseListener::Handler< HandlingType >( HandlingObject )
    {
    }
};

class ButtonDownCounter
   : public MouseHandler< ButtonDownCounter >
{
private:
    unsigned int count;
public:
    ButtonDownCounter()
        : MouseHandler< ButtonDownCounter >( *this )
    {
        count = 0;
    }
    void handle( const LeftButtonDown & )
    {
        ++count;
        std::cout<< "LeftButtonDown" <<std::endl;
    }
    void handle( const ButtonDown & )
    {
        ++count;
        std::cout<< "AnyOtherButtonDown"<<std::endl;
    }
};

void sendMessagesTo( MouseListener &ListeningObject )
{
	ListeningObject.listen( LeftButtonDown() );
	ListeningObject.listen( RightButtonDown() );
}

void test()
{
	ButtonDownCounter counter;
	sendMessagesTo( counter );
}

Dieses Pattern ist also ähnlich einfach zu benutzen wie die Lehrbuch-Variante (naja, vielleicht etwas komplizierter).
Durch diesen message-dispatch Mechanismus sind auch noch andere features denkbar. So ist es etwa möglich, alle Messages an einen Listener zu geben, dessen (polymorpher) Handler diese Messages wiederum an Objekte mit zur Compilezeit veststehende Objekte verteilt. Dadurch kann man mit dem Overhead von nur 1 virtual function call pro Message an beliebig viele Typen verteilen.
Dadurch, dass die Daten der einzelnen Events jetzt in structs stecken, könnte man eine eine message queue bauen, die Messages zwischenspeichert (das ist aber alles andere als trivial).

So, ich hoffe ihr habt bis zum Schluss durchgehalten, ist jetzt doch etwas länger geworden, als ich dachte
Über feedback und Kritik würde ich mich sehr freuen.

structs stecken, könnte man eine eine message queue bauen

Hast du dir die Nachrichtensysteme von SDL, sfml oder Qt schon angesehen? Oder aber das Konzept message passing in Smalltalk? Weiterhin verstehe ich nicht, welches Problem du loesen moechtest oder was deine eigentliche Frage ist.