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