From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-02-26 09:43:42
On Tuesday 26 February 2002 04:56 am, you wrote:
> I think the signals library should be accepted into boost. I have used it
> breifly and can see it being extremely useful in the future. However I am
> slightly concerned that Doug has maybe tried to put too many features into
> the library. To echo Søren's remarks earlier, I personally can see no use
> for the return value feature, and I feel the same about the 'named signals'
The justification for named connections is that they are very handy when your
disconnections don't coincide with object destruction, and it is unwieldy to
keep lots of connection objects around in your class because of this. Named
connections allow simple connect/disconnect pairing without using connection
> The main problem I have with these features being there is that they each
> add to the size of a signal object - sizeof(boost::signal<void>) is 136
> bytes on Borland C++ 5. I would personally prefer a more lightweight
> signal, especially where I feel that most of the weight is being added by
> marginal features. YMMV of course.
Ouch! I just checked the size of boost::signal<void> on the compilers I have
easy access to, and here are the results:
Borland C++ 5.5.1/Windows 2000: 80
MSVC 6.0sp5/Windows 2000: 28
GCC 2.95.3/Linux 2.4.x: 24
GCC 3.0.3/Linux 2.4.x: 16
Comeau 18.104.22.168/Linux 2.4.x: 20
I'm not sure why the huge difference between Borland and the other compilers,
or the reason for the difference between the 136 you got on Borland and the
80 I ended up with.
If I can work around Borland inefficiencies in this area without hurting the
other compilers, I will.
I can try to characterize the cost of the two features you mentioned:
1) Return values cost nothing in terms of object size, unless you would
also remove combiners. In this case the entire system would be greatly
simplified, but would lose its configurability entirely.
2) Connection names are more costly: naming connections requires an
std::map, though that is allocated dynamically and does not contribute to the
signalN<...> object size.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk