I've written something simular as is current talked about in the thread 'Interest in a runtime dynamic dispatch library', but since the callbacks are called when some event occurs, I call them 'event servers'. I suppose that might include a 'dispatcher', but I wouldn't have a clu which part ;). And to be honest, I can't think of much that makes this useful without the whole thing. The concept of my 'event servers' is the following: The user declares(/derives) a class which represents an 'event server'. Each event server services events of a certain 'type'. In particular, the type of the data that is returned as parameter of the callback function is fixed per event server (though totally arbitrary per event server class). I call this 'the event type'. Thus, FooEventServer foo_event_server; It is possible to instantiate any number of event servers, even of the same type, though mostly one would just instantiate a single instance for each given 'event type', because each instance of an event server would have it's own queue for events that weren't handled yet. At an arbitrary number of points in the code it is possible to request events of such a type, by calling a method of the server. Such calls pass a reference of an arbitrary class type as well as a member function pointer to a member function of that class type: the call back function. // Request events from foo_event_server. foo_event_server(my_event_client, &MyEventClient::call_back); The only restrictions here are that the callback function must return a bool and takes the corresponding 'event type' as parameter. class MyEventClient { ... bool call_back(FooEventServer::event_type const& event_type); or just bool call_back(FooEventType const& event_type); }; Optionally, it is possible to pass a 'cookie' object (also of arbitrary type), in which case the call back function also needs to accept an argument of the type of this cookie object: the cookie will be returned as-is to the caller, when the event occurs. class MyEventClient { ... template<COOKIE> bool call_back(FooEventServer::event_type const& event_type, COOKIE cookie); }; ... // Request events from foo_event_server. foo_event_server(my_event_client, &MyEventClient::call_back, cookie); // cookie can be anything. Finally, it is possible to define the event server such that a given type (arbitrary, but fixed per event server) can be passed along with the request, I call this the 'event data'. This data object can be used to decide if an event of a given type is really matching the request of that client or not. // Request events from foo_data_event_server. foo_data_event_server(request_data, my_event_client, &MyEventClient::call_back); Once the callback function is called (being passed an object of the 'event type', and optionally the 'cookie' object), it can either return false-- meaning that the request should stay and handled again, or true-- meaning that the request should be removed (it was the last time the call back was called).

From the point of view of the 'client', there is just one more thing: when requesting an event from the server, it can also provide a 'busy interface object'; this object handles cases where an event occurs, but the client (the owner object of the call back function) is 'busy' and cannot handle the event. Since this is part of a library for event driven applications that I wrote, every call should return as soon as possible. So, if the client is 'busy' then the fact that the event occured should be queued somewhere until it becomes not-busy again; this is done by the 'busy interface object'.

I've written a few event servers in the mean time; below are some examples of working code. Please note that this post shows what is possible from the point of view of the 'client' (the one requesting an event, and the object that gets the call back). It doesn't go into the inner workings of the event servers that I wrote. Example 1. This requests a user answer to some text question. Each 'client_session' (a socket connection of the current client (not the event client, that would be current object *this)), has it's own instance of a 'user_answer_event_server' that dispatches the answers of the user behind that client. M_identity->client_session().user_answer_event_server (UserAnswerRequestData(M_identity, "What server should I connect to (type: <server> [<port>])?"), *this, &ServerConnection::received_server_port_answer); The 'request data' of the user_answer_event_server is obviously UserAnswerRequestData, and exists of a pointer to some application specific 'identity', as well as the actual question. When the user answers the question, the method 'received_server_port_answer' is called (of the current object (*this)). Example 2. Each 'server_session' (a socket connection to a server on the internet (not the event server)) has an 'event server' instance, here returned by message_event_server(). MatchRequest match_request(M_identity); match_request(396). // Numeric 396 reply localserver(prefix). // From local server mynick(0). // to me. wildcard("*.users.undernet.org", 1). // Parameter 1. exactmatch("is now your hidden host", 2); // Parameter 2. // Request an event for matching messages. M_server_session->message_event_server()(match_request, *this, &ServerConnection::hidden_host); The last line requests 'hidden_host' to be called back (of the current object) as soon as a message from the server is received that matches the given match_request. Obviously, MatchRequest is an arbitrary custom object (that allows me to very efficiently match incoming server messages) but it is completely linked to this particular event server: it is the 'event data' type of this event server. Example 3. char service_mode = 'x'; ASSERT(M_state == authentication_sent); M_state = umode_i_sent; *M_server_session << "MODE " << M_identity->server_out_nick() << " +i" << service_mode << "\r\n"; UserModeMask mask('i'); mask |= service_mode; // Request an event for an expression to become true. ON_TRUE((*M_identity->user_mode() & ConstExpression(mask)) == ConstExpression(mask), *this, &ServerConnection::invisible_event); Ok, this one isn't entirely fair - as 'ON_TRUE' is a macro (see below). The last line causes the callback 'invisible_event' to be called, again a method of the current object (*this), as soon as the expression given in the first argument of the macro becomes true. The macro is defined as #define ON_TRUE(expr, action...) do { (expr).create_event_server()(action); } while(0) In this case, a temporary event server is created for every event request; one for each expression that has to be evaluated. The to-be-evaluated expression is thus not the event data - but incorporated into the event server a lot more than that. [Here is how this works: user_mode() returns a reference to an object of type Watched<UserModeMask>. By putting the '*' in front of it, it can be used in an Expression as above, otherwise it just acts as a UserModeMask. The fact that it is used in the expression above tells the Watched<UserModeMask> object that it is used in that particular expression. When the Watched<UserModeMask> changes value, it notifies the event server - which in turn re-evaluates the whole expression to see if it became true, calling the call back if it did.] Example 4. This code requests a timer event. 'bi' is a busy interface object in this case: struct timeval timeout = { 2, 0 }; timerRequest(timeout, *this, &alarm_tst_app_ct::its_time, bi); This will call 'its_time' of the current object, after the event data 'timeout' has expired and the busy-interface object (bi) is not set busy -- otherwise the call back will be delayed until the moment that the busy-interface object is set un-busy again. However, the 'event type' (the object passed to the callback function) contains the actual time at which the timer expired-- so, even though the callback might be a little later, the client always is remembered at which the event really occured. As you can see, the number of possibilities are endless. It is therefore not possible to write one interface that fits all. Things like the expression evaluation, the message matching routines and the code that handles the user questions, all have to be customized code, of course. As a result, writing an 'event server' is a lot of work - even when you already provide the frame work, and all possible common code. Nevertheless, the interface provided by the event library makes it possible to get the cookie and busy interfaces for free. And often it is only needed to declare the EventType class (the type of the parameter passed back the call back function), define a base class for event requests, and write the 'trigger' function that actually figures out which request matches the current event. The 'UserAnswer' event server exists of 179 lines of code (including copy right notices and comments in the files). The expression evaluation event server exists of 1247 lines, while the message matcher needed 488 lines of extra code. The timer event server is part of my event library. What I like about this design is that the class types that are used for the cookie as well as the event client (the owner of the call back function) can be totally arbitrary for every event request (while remaining 100% type-safe of course - it doesn't do any casting). Also, the interface for the many ways an event can be requested (with or without cookie, and with or without a busy interface) involving rather complex templated member functions on top of that, could be totally re-used. It is not necessary to put time into that for a new event server. Finally (something I didn't even began to get into in the above), all of this delete-safe. When any object involved is deleted at any moment, then the events simply don't occur anymore and memory is freed as appropriate. Ie, suppose you have a Watched<> object that is being used in multiple expression, but the object owning the Watched<> object is destroyed... no problem. The expression will simply not evaluate to true anymore: the event requests are deleted, the temporary event server is deleted, no pain. Same when an event client that requested the call back is destroyed: that fact automatically causes the event server to not call it's call back method anymore. Deleting an event server, obviously also cleans up any pending events. In order to get this garbage collecting working smoothly, I have added one more demand for event clients: they have to be derived from 'EventClient'. This is not really necessary, but it doesn't seem a problem to me (one of their methods already has to know about the event server, as it takes the 'EventType' as parameter, so the class clearly is event-server-aware anyway). Regards, -- Carlo Wood <carlo@alinoe.com>