Re: [boost] Signals Review

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-02-28 11:37:12

On Thursday 28 February 2002 06:03 am, you wrote:
> What about just a std::multimap< ... > and keeping a iterator to the
> last unnamed connection. Something like the following will give
> O(1) insert time for unnamed signals:
>
> // unnamed connect
> connect( slot ) {
> 	if ( last_unnamed == multimap.end() ) {
> 		last_unnamed = multimap.insert(
> 			pair( unnamed_value, slot )
> 		);
> 	} else {
> 		last_unnamed = multimap.insert(
> 			last_unnamed,
> 			pair( unnamed_value, slot )
> 		);
> 	}
> }
>
> // named connect
> connect( name, slot ) {
> 	multimap.insert( pair( name, slot ) );
> }
>
> I also thing this will give a FIFO ordering of unnamed connections.
> But I an not sure, my STL documentation is not clear about this.
> The code can be modified to give a LIFO ordering if you prefer.

Unfortunately, this is not the case. STL associative containers are typically 
balanced trees, so even if you give a correct hint when insertion, there may 
still be O(lg n) rotations to rebalance the tree. Also, without giving a 
specific order to the unnamed slots via a name or priority, there is no 
guarantee regarding the order in the multimap. Remember that the 
multimap::insert that takes in iterator to insert at considers the iterator 
as a 'hint' and not an absolute position.

> Another solution would be to have two signal types, one that support
> named connections and one that don't. This way you don't pay for
> some thing you don't need.

I'd prefer not to go down this road only because it adds additional 
complexity for the user.

> Besides from the calling sequence I thing the named connection
> signal can be build on top of a unnamed signal.
> The named-connection signal just have to store the connection
> objects in a std::multimap.

Yes, this is true. However, it seems that if we're going to have named 
connections, we might as well use them to determine the calling sequence, 
which would seem to exclude building named signals on top of unnamed signals. 

[reordered]
> I thing there also need to be some kind of ordering between unnamed
> slots. It is just to hard to make sure your program works with
> all possible calling sequences. 

This same argument could be applied to groups of connections: they should 
have strict ordering because the same problems can occur. It seems to me that 
if an ordering mechanism exists (in the form of group names), then it is 
unnecessary to have ordering within a group: if you have dependencies between 
your slots, give them names (perhaps "priorities" is a better term) to ensure 
they are called in the correct order. Note that basing the calling sequence 
on a FIFO/LIFO ordering of unnamed slots is a little dangerous anyway, 
because it is easy to break that ordering. One based on specific priority 
levels, where dependencies are spelled out to the programmer and signal, will 
always be safer. 

Note: I am not free from implementor's bias, and it may be clouding my 
judgement :). Without ordering within a group and without ordering of unnamed 
connections, the implementation reduces to a simple multimap that orders 
based on the names/groups/priorities, and all named slots precede all unnamed 
slots.

        Doug