Boost logo

Boost :

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
> > > logarithmic complexity of inserting a new element in a particular
> >
> > 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
> to queue the additions. In both cases you need to queue up deletions
> 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
   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

> But yes, it could be a policy <shudder>.

It be nice. I think that it would make signals more suitable for large scale
where optimizations are of a great importance.

In a way, combiner is already a policy.


Boost list run by bdawes at, gregod at, cpdaniel at, john at