Re: [boost] enumeration interface for boost::signals

From: Douglas Gregor (gregod_at_[hidden])
Date: 2004-03-17 12:22:55

On Thursday 11 March 2004 10:18 pm, E. Gladyshev wrote:
> I see. As soon as the slot insertion happens at a consistent
> relative position, the semantic is consistent.
> Does it mean the all nested insertions put the new slot
> at the end of the slot list so that the new slot will be called
> during the current signal propagation call?
> If signals supported the slot ordering then
> what would the insertion semantic look like?

This is the slot ordering issue again :) If you insert with a group that 
precedes the group being called, it will not be called during that 
invocation. If you insert with a group that follows the gorup being called, 
it will be called during that invocation. If you insert in the same group as 
the one being called, you don't know because there is no guaranteed ordering 
within a group [*].

> > Which operation's complexity are you concerned about? I've never heard of
>
> a
>
> > performance problem...
>
> Sometimes, from the event property values, the signal source can
> tell what slot exactly or subset of slots need to be called and
> that other slots should not be bothered with this event instance.
> In what case the signal source should havea random access to the slots.
> Otherwise it will have to propagate the event to *all*
> slots and let them decide on what to do. If the number of slots
> is not too big, this works just fine. However if the number
> of slots is huge, the optimization is important and one
> of the optimized solutions will most likely require
> a random access to slots based on the slot index and slot ordering
> support, including slot insertions at specified
> positions in the slot list.

Ok, I understand this. I thought you were referring to a different source of 
inefficiency.

In any case, getting random access (traversal) iterators and fast ordered 
insertions/deletions is not a trivial task. Did you have some particular data 
structure in mind that could do this?

Here is a question for you: would the ability to invoke only the slots within 
a particular group solve this problem? That is implementable within the 
current semantics, although it will not give random access.

> Another way to optimize requires the ability to call the
> slot that is referenced by the signals::connection instance.
> In what case, the user can handle all the ordering and
> indexing stuff on her own.

We'd be adding a connection_type for each signal, which would derive from 
signals::connection. It can be done, of course, with a little internal 
shuffling and some slight user code breakage.

> For instance, the user could have 
> a separate ordered vector of signals::connection
> objects and call the connected slots as needed.

You might be better off with a vector of boost::function objects.

> I'd say that instead of changing the existing
> signals semantic to support the slot ordering
> and random slot access, I would make it possible
> to access and call slots that are referenced
> by signals::connection objects and leave the rest
> to the user. In a way, it is just an
> extension to the combiner semantic.
> Indeed with combiner, the user can propagate the event
> as she likes anyway except that she has no idea
> what slot is what (it is really strange to me).

You usually can't tell what slots you're calling anyway, because type 
information is lost to the user once you've connected the slot. The point of 
a callback is that you don't know where you're calling back to.

> Are there any problems with giving the user
> an access to the slots referenced by
> signals::connection objects that don't see?

Other than the proliferation of classes derived from signals::connection, not 
really.

> I'll try to give a real life example once again.
> In Win32 the standard listbox control can generate
> messages that have the listbox item index as one
> of the message parameters.
> Imagine that each item in the listbox is implemented
> as a signal slot.
> How would you propagate the Win32 messages
> that are targeting separate listbox items

If we had the ability to invoke only the slots that were part of a particular 
group, you would make the group the listbox item number. Slots that are 
interested in all item numbers would not have any group; slots interested in 
a particular item number would be in that group.

Item numbers aren't all that great to use, because items can be inserted or 
deleted. You'd probably be better off using some other form of identifier for 
list items.

It's a bit of a strange problem. I don't believe that random access traversal 
iterators are the right answer; calling via a signals::connection derived 
class is rather redundant, because you'd be cloning the signal's internal 
ordering. Invocation of slots in a particular group might do it for you, but 
only if you don't need to deal with, e.g., slots that accept a subrange of 
item index numbers.

        Doug

[*] Unless someone can convince me that one can portably order elements with 
the same key within a multimap.