Re: [boost] enumeration interface for boost::signals

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-03-07 21:44:09

From: "Douglas Gregor" <gregod_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, March 07, 2004 5:31 PM
Subject: Re: [boost] enumeration interface for boost::signals

Thanks a lot for the clarifications.

>
> This you can do. The slot call iterator is just an iterator, but the
> dereference operator actually invokes the slot. So, for instance, if you'd
> like to keep calling slots until one of them becomes true, you might write
a
> combiner like this:
>
> struct until_true {
>   typedef bool result_type;
>
>   template<typename InputIterator>
>     bool operator()(InputIterator first, InputIterator last)
>     {
>       while (first != last) {
>         if (*first) return true;
>         ++first;
>       }
>       return false;
>     }
> };

I must have missed it in the docs. Is InputIterator is a random access
iterator?
Can I do *(first+2)? When do iterators become invalid?
For example can I store an InputIterator instance for later?
How is InputIterator connected to groups?
What is the order... is the 'last' iterator is the last connection?
The doc says that the order of slot calls is unspecified,
is it true for InputIterators?

Is it possible to have stateful combiners?
If so, how can I modify the combiner's state before
generating a signal?

For instance is it possible to do something like this:

struct call_slot
{
   bool b;
   typedef bool result_type;

   template<typename InputIterator>
     bool operator()(InputIterator first, InputIterator last)
     {
        if(b)  do_something1( first, last );
        else do_something2( first, last );
     }
 };

>
> > A related question is if I have an instance of
boost::signals::connection,
> > is it possible to get an access to the slot that this connection is
> > referencing?
>
> No.
>
> Back when Signals was designed, there was no way to use this capability
> because boost::function objects were entirely opaque. Now they're a bit
less
> opaque (in CVS, at least, because of operator==), so this could be seen as
> more of a hindrance.

Mybe there is another way to accomplish what I want?
I'd like to have an efficient method for "capturing" signals,
so that a slot can be temporarily designated as a
sole signal destination.

typedef boost::signals::signal< void (int) > my_signal;
struct client {...};

main
{
  my_signal sig;

  client c1, c2;
  boost::signals::connection con = sig.connect(c1);
  sig.connect(c2);

  set_capture( s, c1 /*or should it be con?*/ );

  sig(1);  //the signal is sent to c1 only

  remove_capture( s );

  sig(1);  //the signal is sent to all slots
}

Is there a natural way to implement set_capture/remove_capture?
In other words, was such a feature considered during the Signals design?

I am sorry for so many questions.
If there are some references that I need to look at, I'd happy to do so.

Eugene