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
From: "Douglas Gregor" <gregod@cs.rpi.edu> To: <boost@lists.boost.org> Sent: Tuesday, March 09, 2004 9:01 PM Subject: Re: [boost] enumeration interface for boost::signals 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