Re: [boost] Signals Library Review

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'
> feature.

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 
objects. 

> 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 4.2.45.2/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. 

        Doug