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.