Boost logo

Boost :

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.

> 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


Boost list run by bdawes at, gregod at, cpdaniel at, john at