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

From: Douglas Paul Gregor (gregod_at_[hidden])
Date: 2004-03-07 23:22:28

On Sun, 7 Mar 2004, E. Gladyshev wrote:
> I must have missed it in the docs. Is InputIterator is a random access
> iterator?

No, it's an input iterator.

> Can I do *(first+2)? When do iterators become invalid?

Assume input iterator semantics, only.

> For example can I store an InputIterator instance for later?

No.

> How is InputIterator connected to groups?

Not at all :)

> What is the order... is the 'last' iterator is the last connection?

Yes, but remember that the order is very loosely specified.

> The doc says that the order of slot calls is unspecified,
> is it true for InputIterators?

Yes. The order of slot calls is unspecified within a group.

> Is it possible to have stateful combiners?

Yes.

> If so, how can I modify the combiner's state before
> generating a signal?

Hmmm, that's a problem.

> 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 );
>      }
>  };

Yes, but it seems that I've omitted any way to get to the combiner. Sounds
like something we should add.

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

Not that I can think of.

> In other words, was such a feature considered during the Signals design?

No, it wasn't. What sort of application do you need it for? It's
interesting.

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

Just the reference docs.

        Doug