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

From: Douglas Gregor (gregod_at_[hidden])
Date: 2004-03-11 16:20:31

On Wednesday 10 March 2004 01:22 am, E. Gladyshev wrote:
> I guess signal can be specialized on containers with
> "unstable" iterators such as vector and
> auto-generated uniq keys can be added to slots.
>
> Something like:
>
> struct signal
> {
>  operator()(...)
>  {
>    for( size_t i = 0; i < slots.size(); ++i )
>    {
>        key k = slots[i].get_key();
>        *slots[i];   //make the call
>        if( k != slots[i].get_key() )  //something is changed
>           i = find_key(k);  //reset the index
>    }
>   }
> };

That doesn't play so well with the slot call iterators, though. Anyway...

> However I'd prefer queueing "nested" insertions and deletion in all cases.
> It is not consistent that signals is queueing deletions but not insertions
> now.

Oh, my apologies, I wasn't quite clear on what the queueing meant. 
Disconnecting a slot while in a nested call immediately disables the slot (so 
it will not be called again), but the slot is not physically removed from the 
slot list until we exit the top-level nest. So the insert/delete semantics 
are equivalent, because both occur immediately from the user's point of view.

This would not be the case with a vector; we'd have to delay insertions.

> > But yes, it could be a policy <shudder>.
>
> It be nice. I think that it would make signals more suitable for large
> scale applications
> where optimizations are of a great importance.

Which operation's complexity are you concerned about? I've never heard of a 
performance problem...

        Doug