Boost Users :
From: Edward Diener (eddielee_at_[hidden])
Date: 2003-08-27 16:05:21
> --- 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
>> 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
> 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
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
>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
> 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.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net