From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-02-18 07:54:34
Jody Hagins wrote:
> What I want is the ability to have a single signal that can dispatch
> multiple signatures (but I do not want to give up any type safety).
> For example, what I have now is very much like:
> boost:multisignal sig;
> The underpinning is based upon typesafe access (demux based on the
> type) to the right bost::signal instance, and then forwarding the
> signal dispatching to that signal, and I have a protoyype that allows
> this as well:
> sig(another_class(), and_another_class());
> This provides power and flexibility to many of our applications, and
> allows us to create specific event objects, and then dispatch them
> via a single multisignal object, not really caring about the type of
> the object that we are dispatching, since the multisignal will
> correctly (and safely) take care of that redirection.
> A typical "slot" might have multiple handler functions...
> struct some_slot
> void operator()();
> void operator()(some_class const &);
> void operator()(another_class const &, and_another_class const &);
> Currently, the connection is a bit tricky, and has to be done
> explicitly (or wrapped with clever type lists)...
> so that the multisignal knows that a_slot is interested in signals
> that have some_class as the signature. I have not yet found a way to
> automatically deduce all the "operator()" function signatures. If I
> could, then connection to all the proper underlying signals would be
> much nicer as well.
One alternative approach would be to pass a signature to connect:
sig.connect< void (some_class const&) >(a_slot);
or, going a bit further in that direction, require a nested signature list:
void operator()(some_class const &);
void operator()(another_class const &, and_another_class const &);
void(some_class const &),
void(another_class const &, and_another_class const &)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk