Re: boost::function syntax

From: shyamemani (shyamemani_at_[hidden])
Date: 2003-08-27 12:48:48

--- In Boost-Users_at_[hidden], "Edward Diener"
<eddielee_at_t...> 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.

> 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.

I do not doubt the power of boost::function and
boost::signal libraries but one cannot dismiss the
proven paradigm of call back interfaces. 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.

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. 

Shyam