On Thu, Aug 6, 2015 at 4:10 PM, Michael Powell wrote: On Thu, Aug 6, 2015 at 4:01 PM, Nick Stokes

wrote:

I'm not sure what you're shooting for.

Doesn't the last "broader picture" paragraph help explain?

When I'm approaching signals/slots or any sort of event driven system, I generally treat that

"that" == ?

as a single event, with 2+ connections, events being handled but each subscriber.

i.e. your first connection handles the double value; the second connection would accept a double, and convert it to int to pass it along to another int-based method

The 2+ methods (of ComboSlot) corresponds to entirely independent events. The event driven system fires them separately on separate code paths. The system fires as many of any of these in any order and count. The only invariant I want to impose is that they are always connected (or unconnected) in groups. I.e. there is no allowed scenario where a event1 is handled but event2 isn't, and both events are handled by the same underlying handler (ComboSlot). Again, is my "broader picture" example useful in anyway? Thanks Nick

On Thu, Aug 6, 2015 at 4:37 PM, Nick Stokes wrote:

On Thu, Aug 6, 2015 at 4:20 PM, Nick Stokes wrote:

...

On Thu, Aug 6, 2015 at 4:10 PM, Michael Powell wrote:

...

On Thu, Aug 6, 2015 at 4:01 PM, Nick Stokes 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users