Re: [Boost-users] [signals2] can a combiner return the slot iterator range?

Subject: Re: [Boost-users] [signals2] can a combiner return the slot iterator range?
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2015-08-06 17:26:10

On Thu, Aug 6, 2015 at 4:37 PM, Nick Stokes
<randomaccessiterator_at_[hidden]> wrote:
>
>
> On Thu, Aug 6, 2015 at 4:20 PM, Nick Stokes <randomaccessiterator_at_[hidden]>
> wrote:
>>
>>
>>
>> On Thu, Aug 6, 2015 at 4:10 PM, Michael Powell <mwpowellhtx_at_[hidden]>
>> wrote:
>>
>>> On Thu, Aug 6, 2015 at 4:01 PM, Nick Stokes
>>> <randomaccessiterator_at_[hidden]> wrote:
>>>
>>> I'm not sure what you're shooting for.
>>
>>
>>
>> Again, is my "broader picture" example useful in anyway?

If it's my, I try to drive toward simplicity. I'm not sure what your
real world requirements are, or how these many facets necessarily grew
feet, per se, to answer beyond what I have.

I do know that's one of the "features" of a pattern like event
handling, signals/slots in particular, is to decouple the consumer
from the producer, so that you don't need to know whether you are
producing a 3.14 (PI) or a 3 (presumably, derived from the same PI
value). Could say, 2.718 (e) or 2, for the same illustration, no? To
me that's just another subscriber on the signaled method.

HTH

> perhaps, the short "use-case" example I provided was misleading:
>
>
>> // in use
>> for( ComboSlot& cs : sig() )  {
>>    cs.method1(3);
>>    cs.method2(3.14);
>> }
>>
>
>
> This gives the false impression that I am calling both methods in order.
> That is very misleading indeed, sorry.  Here is perhaps a more clarifying
> use case:
>
>
>
> struct EventGenerator {
>
>       void event1( int i )  {
>                // want to launch all listeners of event1
>       }
>
>       void event2( double d) {
>                // want to launch all listeners of event2
>       }
> };
>
>
> One implementation is to define two separate signals for each even and
> manage their slots independently:
>
>
> struct EventGenerator {
>       typedef signal< void(int) >  sig1_t;
>       typedef signal< void(double) >  sig2_t;
>
>       void event1( int i )  {
>         sig1(i);
>       }
>
>       void event2( double d) {
>            sig2(d);
>       }
>
>       void connect( std::shared_ptr<ComboSlot>& e ) {
>            sig1.connect( sig1_t::slot_type( &ComboSlot::method1, e.get(), _1
> ).track(e) );
>            sig2.connect( sig2_t::slot_type( &ComboSlot::method2, e.get(), _1
> ).track(e) );
>       }
> private:
>      sig1_t sig1;
>      sig2_t sig2;
> };
>
>
> The invariant that signals must be connected together to a same underlying
> event handler is satisfied. But this implementation quickly gets out of hand
> as number of events increase.
>
> Another alternative would be:
>
> struct EventGenerator {
>       typedef signal< ComboSlot&(),  RangeCombiner > sig_t;
>
>       void event1( int i )  {
>            for( ComboSlot& cs : sig() ) {
>                cs.method1(i);
>                // also imagine, i can do arbitrary things there. e.g. break
> loop what not
>            }
>       }
>
>       void event2( double d) {
>            for( ComboSlot& cs : sig() ) {
>                cs.method2(d);
>            }
>       }
>
>      void connect( std::shared_ptr<ComboSlot>& e ) {
>            ComboSlot* cs = e.get();
>            sig.connect( sig_t::slot_type( [cs](){ return cs;} ).track(e) );
>            // done - number of events don't matter
>       }
> private:
>     sig_t sig;
> };
>
>
> hopefully this clarifies the use case.
>
> Thanks
> Nick
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users