Re: [boost] [signals2] Uncombined signal

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:
>> 
>> 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