Re: boost::function syntax

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-08-27 16:05:21

shyamemani wrote:
> --- 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.

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.