----- Original Message ----- From: "Douglas Gregor" <gregod@cs.rpi.edu> [...]
That doesn't play so well with the slot call iterators, though. Anyway...
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
No, it doesn't. There is another way, please read on... 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