Subject: Re: [boost] [signals2] Uncombined signal
From: Ivan Le Lann (ivan.lelann_at_[hidden])
Date: 2013-04-18 18:28:08
Le 18 avr. 2013 Ã 17:24, Frank Mori Hess <fmh6jj_at_[hidden]> a Ã©crit :
> On Wed, Apr 10, 2013 at 7:44 PM, Ivan Le Lann <ivan.lelann_at_[hidden]> wrote:
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk