-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Lukasz Sent: Thursday, June 21, 2007 1:56 PM To: boost-users@lists.boost.org Subject: [Boost-users] problem... maybe boost could help
If anyone has some brilliant idea as to how this can be done (if it can), then i would appreciate the input.
[Nat] No such thing around here, just a half-baked thought. I wonder whether it would make any sense to introduce, for a given event subclass type, a canonical filter listener object. For a simple event class hierarchy, it might even work to register such listeners in a new map keyed by the typeid().name of the event subclass. So any receiver can look up any specific filter listener in a central registry. Each filter listener itself contains a registry of dependent receivers who want to process the events it's willing to pass. Its own processing method dynamic_casts each event to the desired event subclass type, and forwards only successfully-downcast events. Let's say we have receiver class SomeReceiver with a method that wants to process only EventTypeA events (processEventTypeA()), and another method that wants to process only EventTypeB events (processEventTypeB()). The SomeReceiver constructor looks up the canonical filter listener for EventTypeA and registers bind(&SomeReceiver::processEventTypeA, this, _1) with that filter listener. Similarly for processEventTypeB(). The filter listener could be a template class, and the registry through which they're looked up could use find-or-create logic to instantiate each specialization of filter listener on demand. That way you wouldn't need to maintain a central list of instantiations. So it would be up to the receiver's self-registration code to decide whether it wants to handle all events or only some subclass. If it wants to receive all events, it registers with the central event dispatcher as now. If it wants to receive only specific events, it registers instead with the filter that forwards only those specific events. Filter listeners, of course, listen to the central dispatcher. Or if you want to get fancy with the event hierarchy -- let's say EventTypeA and EventTypeB are each subclasses of EventTypeABBase -- I suppose you could register the filter listeners for each of EventTypeA and EventTypeB on the filter listener for EventTypeABBase. That way the filter listeners for EventTypeA and EventTypeB impose less overhead because they only see EventTypeABBase events. (If you combine this idea with a fully generic filter-listener template class and on-demand filter instantiation, the filter listener for EventTypeA needs to know enough to register itself with the filter listener for EventTypeABBase. It's not yet clear to me how to automate that. I guess you could hand-specialize the filter listeners for EventTypeA and EventTypeB so they'd know where to self-register. Alternatively, it's not strictly necessary for the EventTypeA and EventTypeB filter listeners to register on the filter listener EventTypeABBase -- that just appeals to my sense of elegance. They could all be neighbors on the central dispatcher.) I hope this will at least prompt other people to contribute more sensible ideas... ;-)