Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk