Boost logo

Boost Users :

From: Doug Gregor (dgregor_at_[hidden])
Date: 2007-02-07 15:10:21


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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net