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; sig(); sig(some_class()); sig(yet_one_more_class());
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)...
sig.connect<some_class>(a_slot);
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.
That's nice. 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: struct some_slot { void operator()(); void operator()(some_class const &); void operator()(another_class const &, and_another_class const &); typedef list< void(), void(some_class const &), void(another_class const &, and_another_class const &) > signature_list; };