On Feb 7, 2007, at 2:57 PM, Timmo Stange wrote:
Doug Gregor wrote:
Not necessarily. One could have a "signal_impl_with_combiner" template that derives from "signal_impl", and stores the combiner. Most of the shared code will still be in signal_impl, of course.
Right, I'm going to use that, but: While I was running the first experiments with a version of Signals from which I stripped grouping/naming, I've now had a closer look at named_slot_map. I know that it has been con- sidered a not so lucky design and one can tell from the code that it gave you some headaches. I frankly find the performance aspects unacceptable for my personal use (shared_ptr<void> to a heap allocated group name, boost::function as a comparison operator), so the only option for me seems to be turning the named_slot_map into a template, with the obvious propagation effects for the rest of Signals. I would also add a signals::no_name type to be able to get an instantiation which would use a list or deque for the slots.
I know that this will result in the infamous template bloat on some compilers, with code duplication for each Group/GroupCompare pair, potentially in several compilation units. On the other hand I won't be able to find the necessary motivation to work on some- thing I'm never going to use myself.
So, if such a design change is a show-stopper, I'd rather be told now than later ;).
I would not shed a tear if named slot maps were to disappear, and without the std::map needed for named_slot_map, most of the need for the uses of function/any disappear. Cheers, Doug