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

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-03-11 22:18:22

----- Original Message ----- 
From: "Douglas Gregor" <gregod_at_[hidden]>

[...]
>
> That doesn't play so well with the slot call iterators, though. Anyway...

No, it doesn't. There is another way, please read on...

> 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.

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?

>
> 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.

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. For instance, the user could have
a separate ordered vector of signals::connection
objects and call the connected slots as needed.

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).
Are there any problems with giving the user
an access to the slots referenced by
signals::connection objects that don't see?

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

Eugene