AMDG Asif Lodhi wrote:
There are already function pointers in Boost.Signals. I'm pretty sure that this observer requires either the use of global signals (Yuck) or a cyclic visitor (Also not nice). Using a map achieves the same effect, keeping the dispatching logic cleanly separated from the individual handlers and from the event objects. Incidentally, if you look at my last rendition, there is no MPL involved.
It all depends on your design - as to how you implement the observer pattern - spraying global variables all over the place or using proper encapsulation. I am not much into Boost Signals but if it results in clean separation then one should go for it. I just suggested a way to implement the whole thing using simple C++ & basic design patterns without any external library.
Ok. But I think you missed some details. There needs to be a way to register callbacks for each particular event type. Then, there is some code that gets a packet and decodes it to the proper type. Finally, this is dispatched to all the registered signals. The cleanest interface I can think of is to have a holder that you can register the callbacks. This is of course avoiding globals out of principle. Then at the other end the dispatcher does some magic to find which signals need to be called. This can be done either through virtual functions or through a table lookup. It doesn't really matter.
IMO, this is just another means of downcasting. It's safer than a raw static cast because the types will be checked automatically, but not any better than the map solution (Which encapsulates the type check and downcast).
Well, IMO, polymorphically invoking virtual functions is better than downcasting.
As I see it, there is no particular difference in this case. They are two different ways of doing exactly the same thing, and the difference should not be visible to more than about 100 lines of code, max.
This of course is the traditional OO wisdom, but IMO, maps are a perfectly legitimate means of dispatching.
If it results in significant performance gains then, of course, yes. But you cannot know that until you actually measure the performance. Design wise, I'd prefer the OO approach.
Since I have just read the rest of the thread, I would like to add that Boost ASIO and ACE both are designed for this kind of communication stuff. I don't know about ASIO but I do know that ACE does use RTTI, virtual functions and design patterns. I don't think it makes any significant performance difference. As a matter of fact, using templates would often result in faster code than using straight function pointers. A better strategy for Robert would be to actually measure it or use one of Boost ASIO or ACE libraries.
My guess is that a virtual function approach will be negligibly faster. In Christ, Steven Watanabe