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

6 Aug 2015

      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