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

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-03-10 01:22:41

From: "Douglas Gregor" <gregod_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, March 09, 2004 9:01 PM
Subject: Re: [boost] enumeration interface for boost::signals

> On Tuesday 09 March 2004 11:42 pm, E. Gladyshev wrote:
> > > That'd be a much bigger change to Signals. For one, we'd be breaking
the
> > > logarithmic complexity of inserting a new element in a particular
group.
> >
> > Yes, it would need to be a template template parameter for defining
> > the slot container type or a policy.
>
> Right, but you also have to watch the iterator invalidation semantics much
> more carefully. For instance, if you connect a new slot to a signal A from
> within a slot called from signal B, there is no problem in the current
> multimap implementation because iterators are stable. For a vector, you
have
> to queue the additions. In both cases you need to queue up deletions
(that's
> already done, of course).

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

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.

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

In a way,  combiner is already a policy.

Eugene