From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-03-10 01:22:41
From: "Douglas Gregor" <gregod_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.
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk