[signals2] Uncombined signal
Hi, I have a project where I use boost::signals2 in the spirit of the "Signal Return Values (Advanced)" section of the tutorial. That is, I have signals roughly equivalent to : boost::signals2::signal<float (), maximum<float> > sig; // slots produce values accumulated by the combiner Problem comes when I want multiple combiners on the same slots. Especially combiners of different types : You need to duplicate signals, and you need your connection setup code to know about used combiners. IMHO, having a basic signal class with no combiner makes sense. Attached is a POC patch to version 1.50, to add to boost::signals2::signal the method : slot_call_range all (BOOST_SIGNALS2_SIGNATURE_FULL_ARGS(BOOST_SIGNALS2_NUM_ARGS)) const (in boost/signals2/detail/signal_template.hpp)
From there, I think one could use any algorithm/accumulator directly on the signal.all() result. Implementation left aside, any feedback on this ?
Regards, Ivan
On Wed, Apr 10, 2013 at 7:44 PM, Ivan Le Lann <ivan.lelann@free.fr> wrote:
Hi,
I have a project where I use boost::signals2 in the spirit of the "Signal Return Values (Advanced)" section of the tutorial. That is, I have signals roughly equivalent to :
boost::signals2::signal<float (), maximum<float> > sig; // slots produce values accumulated by the combiner
Problem comes when I want multiple combiners on the same slots. Especially combiners of different types : You need to duplicate signals, and you need your connection setup code to know about used combiners.
IMHO, having a basic signal class with no combiner makes sense. Attached is a POC patch to version 1.50, to add to boost::signals2::signal the method :
slot_call_range all (BOOST_SIGNALS2_SIGNATURE_FULL_ARGS(BOOST_SIGNALS2_NUM_ARGS)) const
(in boost/signals2/detail/signal_template.hpp)
From there, I think one could use any algorithm/accumulator directly on the signal.all() result. Implementation left aside, any feedback on this ?
I'm not really grasping your use case/motivation for this. Could you just use a combiner that returns a vector of all the individual return values? -- Frank
Le 18 avr. 2013 à 17:24, Frank Mori Hess <fmh6jj@gmail.com> a écrit :
On Wed, Apr 10, 2013 at 7:44 PM, Ivan Le Lann <ivan.lelann@free.fr> wrote:
Hi,
I have a project where I use boost::signals2 in the spirit of the "Signal Return Values (Advanced)" section of the tutorial. That is, I have signals roughly equivalent to :
boost::signals2::signal<float (), maximum<float> > sig; // slots produce values accumulated by the combiner
Problem comes when I want multiple combiners on the same slots. Especially combiners of different types : You need to duplicate signals, and you need your connection setup code to know about used combiners.
IMHO, having a basic signal class with no combiner makes sense. Attached is a POC patch to version 1.50, to add to boost::signals2::signal the method :
slot_call_range all (BOOST_SIGNALS2_SIGNATURE_FULL_ARGS(BOOST_SIGNALS2_NUM_ARGS)) const
(in boost/signals2/detail/signal_template.hpp)
From there, I think one could use any algorithm/accumulator directly on the signal.all() result. Implementation left aside, any feedback on this ?
I'm not really grasping your use case/motivation for this. Could you just use a combiner that returns a vector of all the individual return values?
I did that. Main problem it that it is not lazy. Not all algorithms dereference all iterators. Now I understand I am abusing signals2::signal here. And I really don't think this class should expose its slots as my dummy patch does. I do think however that the "connection container with slot call iterator" mecanism used in signals2 is useful enough to be publicly exposed. Regards, Ivan
On Thu, Apr 18, 2013 at 6:28 PM, Ivan Le Lann <ivan.lelann@free.fr> wrote:
Le 18 avr. 2013 à 17:24, Frank Mori Hess <fmh6jj@gmail.com> a écrit :
I'm not really grasping your use case/motivation for this. Could you just use a combiner that returns a vector of all the individual return values?
I did that. Main problem it that it is not lazy. Not all algorithms dereference all iterators.
Could you define a bunch of different combiner classes all with a common base class, then alternate between them with signal.set_combiner()? -- Frank
On Thu, Apr 18, 2013 at 11:49 PM, Frank Mori Hess <fmh6jj@gmail.com> wrote:
Could you define a bunch of different combiner classes all with a common base class, then alternate between them with signal.set_combiner()?
Err, actually I don't think that would work given the way signals2 copies the combiner. set_combiner would need to take the combiner as a template type. -- Frank
participants (2)
-
Frank Mori Hess -
Ivan Le Lann