Events, EventManagement and EventListeners - Suggestions?

For simplicity, I recommend you avoid the more complex implementations, and simply go with a system of void pointers, a bunch of different structs for each message, and an enum for the type of message. This method is fast, simple, and robust, and you can handle any dynamic dispatch manually using a switch statement.

For many years I messed about with different message systems, but in the end, I settled for this. [/quote]Do you have any code/pseudo-code?

For simplicity, I recommend you avoid the more complex implementations, and simply go with a system of void pointers, a bunch of different structs for each message, and an enum for the type of message. This method is fast, simple, and robust, and you can handle any dynamic dispatch manually using a switch statement.

For many years I messed about with different message systems, but in the end, I settled for this.

I think he means something like



class Listener
{
public:
virtual void listen( unsigned int MessageID , void *AdditionalInformation )
{
}
//or pure virtual
};

struct MessageA
{
const static unsigned int ID = 0; //or put IDs in a seperate enum
//no data
};
struct MessageB
{
const static unsigned int ID = 1;
char data[10];
};

class SomeListener
: public Listener
{
public:
void listen( unsigned int ID , void *AdditionalInformation )
{
switch( ID )
{
case MessageA::ID:
//....
break;
case MessageB::ID:
MessageB &message = *reinterpret_cast< MessageB* >( AdditionalInformation );
//.....
break;
}
};
};


int main()
{
SomeListener derived;
Listener &base = derived;
base.listen( MessageA::ID , &MessageA() );
MessageB message_b;
//set data
base.listen( MessageB::ID , &message_b );
}



I don't see how this approach is simpler then the one I showed, it definitely has more boilerplate than my example.
I may be wrong, but I think the template solution is faster:

template version overhead:
- virtual function call with 1 parameter: constant time

cast - version:
- virtual function call with 2 parameters: constant time
- switch statement: depending on compiler optimizations either constant time (jump table) , logarithmic (binary search) or linear (naive search)

However, since the compiler has to create a vtable with entries for each message for each specific listener, the template version consumes probably more memory, increasing with both the number of your messages and the number of your listeners (classes).

Are you familiar with templates? If not, you should probably first look into a tutorial about them, and afterwards something about variadic templates (c++0x feature).
If you don't want to spend many hours trying to understand them (well, it took me that long... maybe you learn faster),
you should probably just use the void pointer solution.
To your code: It feels a little bit bloated to me. Think of how to receive a message:
- check subject with getSubject()
- iterate over the std::list from getBody()
- check which actual data is in an element with something like "if( name == "..." ) "
- access the actual data with something like "iterator->object.object"
(I assume you want an instance of that union in your struct?)
- probably even more ifs and whiles for actually processing the message

I don't think you'll be happy with that kind of hard to understand code.
suggestions:
- why do you need a std::list with bodies for each event?
- why do you store the type of a body in a string? Enums are much faster and just as easy to read (maybe even better)

PS: Are you interested in the first or the second code snippet I posted?

Your example pretty much demonstrates exactly what I would do. Template based message filtering is one of the things I tried but again, for simplicity i recommend the message ID + casting method. The amount of boilerplate required to handle messages in a simple scenario seems to be increased, but as your number of message types increases, your template based version will use huge amounts of memory and be considerably complicated. I'm not sure how you would implement decorators, relays, or other types of message handlers with the templated version either - would it require you to do something like,
MessageHandler

I'm closer to electing the publish/subscribe model for message handling.



1. Create a Channel.
2. Build Subscriber List on Channel; Channel Maintains list of of Subscribers.
3. Build Message.
4. Publisher Submits Message to Channel.
5. Channel Pushes Message to Subscriber's Message Queue.
6. Clear Channel.

[quote name='speciesUnknown' timestamp='1312983628' post='4847151']
Your example pretty much demonstrates exactly what I would do. Template based message filtering is one of the things I tried but again, for simplicity i recommend the message ID + casting method. The amount of boilerplate required to handle messages in a simple scenario seems to be increased, but as your number of message types increases, your template based version will use huge amounts of memory and be considerably complicated. I'm not sure how you would implement decorators, relays, or other types of message handlers with the templated version either - would it require you to do something like,
MessageHandler

I quite like this approach as well, though I'm slightly unclear about Channels. From what I gather you can make a comparison to a forum by saying:

Publishers are posters (Me in this topic)
Messages are topics
Channels are the different sections on the forum (Game Programming, Graphics Programming, etc.)

A subscriber then simply looks at the sections he's interested in, and selects the messages that he can use. If that analogy is about right, then I don't believe this approach should be very hard to implement. You could have a templated channel that accepts messages of a certain type that is specified in the template. Publisher submits them to the channel, the Channel forwards them to the subscribers.

• topic-based system, messages are published to "topics" or named logical channels. Subscribers in a topic-based system will receive all messages published to the topics to which they subscribe, and all subscribers to a topic will receive the same messages. The publisher is responsible for defining the classes of messages to which subscribers can subscribe.
• content-based system, messages are only delivered to a subscriber if the attributes or content of those messages match constraints defined by the subscriber. The subscriber is responsible for classifying the messages.
• topic-content hybrid system; publishers post messages to a topic while subscribers register content-based subscriptions to one or more topics.
  I'm pursuing topic-content hybrid filtering. Entities are components-based and the Messaging System (Pubscriber) Components {Publishers, Subscribers, Channels} are automatically added to an entity upon creation to handle inter-communications between other Components.
  
  Pubscriber components are inspired by the event-driven architecture event-flow layers. The Publisher (Generator), Channel, Subscriber (Processor). The Subscriber component maintains a message queue and processes the messages.

Don't worry about design patterns. By message handlers, I was talking about the objects which receive messages and do things with them. There are a variety of different things which might be done with a message.

One handler may directly act when it receives a message - for example, your main game class may exit the game when it gets a certain message.

Another type of handler you might want to use is a filter, which only passes certain message types through.

A third type of handler you might have is a relay - a message handler which, when it receives messages, passes that message to a list of other handlers. For example, if you have an AI controller which has a list of AI creatures which are hunting the player. When one of these AI creatures sees the player, it needs to inform the others where it saw them, so it might send a message to the relay which then sends it to all the appropriate AI creatures in that area.

You might want to put a filter on top of your relay, to cut out messages which are never going to be handled by the AI creatures, thereby cutting out some of the overhead of handling messages which are irrelevant.

A flexible message system enables you to implement all these different types of message handling routines. What is important is not how cool or sophisticated the low level message handing mechanism is, but rather, what high level functionality you need, especially filters and relays.

I got frustrated with template based message relays because I found that I spent a silly amount of time debugging them. C++ does not have an efficient RTTI mechanism, or any kind of dynamic dispatch, so I've found that manual dynamic dispatch and manual type testing is the simplest solution.

...

I really like the idea of filters and relays... how do you use them?