Re: boost::function syntax

shyamemani wrote:

--- In Boost-Users@yahoogroups.com, "Edward Diener" wrote:

...

shyamemani wrote:

...

No, it is not common to want to have a single event handler for events with different signatures. Or to register different event handlers for separate events all with one call. What you are doing is saying that you have these needs, and because a library doesn't fulfill them for you, let's have a language extension to solve your special case.

The normal event-handler paradigm is that:

1) a single event handler handles a single event 2) an event may have more than one event handler

The callback interface I wrote previously follows both these rules, since a event is handled by one function in the interface the single event and single handler rule is satisfied. The collection of interface pointers in the event source takes care of rules 2. Registering an interface pointer is equivalent to creating <n> boost::function instances (where n is number of functions defined in the interface) and passing them different member function pointers of the same class.

That's fine and there is nothing in general wrong with what you are doing here.

...

3) an event handler may handle more than one event, if and only if, the signature for the event handler is exactly the same for different events and there is a way of telling which one of the events has occurred in the event handler.

In the condition when one event handler, handles more than one events, the call back interface is much better implementaion since it calls the correct function using the v-table instead of the hand-coded switch case statement (or some other conditional expression) in the handler.

My criticism is the need to make the client handler derive from the class with the virtual event calls. This is too much coupling to me for a general system. For your specific needs it might be fine. I have no general objection to an event handler which then calls the real events however it wants, through virtual functions if you like. Nor do I have a general objection to registering multiple handlers, from within your own code, at the same time. But when you want to insist that a system must use your own paradigms for your complicated event and event-handling needs, I say that this should not be the purpose of a general purpose event handling design submitted as part of the C++ standard library.

I do not doubt the power of boost::function and boost::signal libraries but one cannot dismiss the proven paradigm of call back interfaces.

I don't know what you mean here. Boost::function implements a callback interface.

Especially in scenarios where events have to be marshalled accross process or network boundaries. In that case since the cost of marshalling is high and only one register function call would be prefered to receive all pertinent events. Also the event parameters have to be tuned to minimize marshalling and are optimized the common use case scenarios of the events.

Then it is up to you to write your own library to deal with marshalling issues. An easy solution would be to create a proxy on the server side ( where Boost::Signals resides ) that works the way you like and minimizes traffic.

A digression: the microsoft __delegate keyword generates code that uses "reflection" and special CLR tags to call the correct function :( and hence it cannot be used with unmanaged c++ code. So though it may provide a similar construct for events handling it is not as powerful and generalized as boost::functions.

I agree, except that it is powerful in its own right in .NET programming.