Boost logo

Boost Users :

From: shyamemani (shyamemani_at_[hidden])
Date: 2003-08-26 20:16:58


So combining this response with your response to Edward regarding
standardization of boost.signal, shouldn't this be a big concern,
since the use-case which I illustrated is quite commonly used in
event based systems?

      But if this can be ironed out I think providing it as a
language extension is better because then C++ can become a language
which has built-in semantics for use of the standard design
patterns. And then we programmar's and designers can live happily
ever after ....

Regards,
Shyam

--- In Boost-Users_at_[hidden], Douglas Gregor <gregod_at_c...>
wrote:
> On Tuesday 26 August 2003 07:36 pm, shyamemani wrote:
> > I hate writing code in mailing list but here is a sample of what I
> > want to do. I have a tree data strucutre class which fires event
and
> > each event has some different parameters that are passed to it.
What
> > I want to illustrate is that by calling one register function I
get
> > access to three events. In boost.signal this would require that
the
> > client call the connect for each event. Is this a good
application
> > for this library?
>
> Perhaps not. When you have multiple events going to a single
listener from a
> single source, signal/slot mechanisms aren't as useful as the
> interface/listener paradigm you are already using. Signals might be
> appropriate if you had a single event that could be any of those
three:
>
> enum NodeEvent { node_added, node_changed, node_deleted };
> boost::signal<void (NodeEvent event, Node* node)> onNodeEvent;
>
> This may have some advantages over the iterface/listener approach
you're using
> (for instance, the automatic disconnect when trackable objects are
destructed
> or the ability to use Bind/Lambda), but it's very likely that
Signals is not
> the right choice for this interface.
>
> Doug


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