Boost logo

Boost :

From: Edward Diener (eddielee_at_[hidden])
Date: 2005-12-22 18:56:22

Douglas Gregor wrote:
> On Dec 22, 2005, at 3:26 AM, Vladimir Prus wrote:
> For I long time I've wanted to have a signal that doesn't permit
> named slots, so that we can replace the horrendous map<name,
> list<slot> > data structure in named_slot_map into a simple
> list<slot>. It even fits into the interface well: we would just add a
> partial specialization of signal<> like the following that uses the
> simple, faster list<slot>-type interface.
> template<typename Signature, typename Combiner, typename
> GroupCompare, typename SlotFunction>
> class signal<Signature, Combiner, void, GroupCompare,
> SlotFunction>;
> It may also be possible to have a common core of list<slot> and when
> Group != void have an auxiliary map from slot group names to
> iterators into the list. This tends to make disconnection rather
> tricky, however.

I do not know if this is doable, or even if you want to do it or
consider it too much work, but I had suggested something like this a
while back: a signal could be created, on an individual signal basis,
with a parameter which says that it does not support named slots, and
that this knowledge should allow you to use a much faster iterator to do
signal processing once the signal is triggered or manipulated. Another
possibility, along the same lines is what you have written just above:
if no named slots have been added for a signal, which you can easily
keep track of with an internal bool per signal, the internal code should
theoretically be able to use simpler algorithms and data structures and
thus speed up signal processing. In either case, those who use signals
with named slots would have no reason to complain of slower signal
processing, since it has already been determined that this slows down
signals to a large extent and they would be told about it in the doc,
while those who do not use named slots would benefit from faster processing.

No, I am not volunteering to implement this in your excellent code, nor
do I pretend to understand the internals of signal, although I have
looked at it occasionally, but just suggesting a possibility along the
lines of "what you pay for you get". I realize this greater flexibility
would come at the price of greater internal complexity and more
difficult maintainability if it could be done, and that is a headache
you may not want to pursue.

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