Re: Signal/slot library

From: Nathan Myers (ncm_at_[hidden])
Date: 2000-04-10 08:22:00

On Mon, Apr 10, 2000 at 07:17:52AM -0000, Karl Nelson wrote:
> This letter isn't meant as a put down, but rather to inform
> that there are far more issues than brought up here.  If boost
> is really serious about getting a signal slot system, there
> is a huge number of trade offs.

Karl Nelson understands callback issues far, far better than anybody 
else I know.  The Boost project cannot go wrong adopting his work or 
his advice.

The Qt signal/slot mechanism is amusing in its way, but it is not C++.
Rather, it relies on a dialect similar to C++ called MOC, which defines 
three extra keywords.  Boost is supposed to be about C++, so Qt can 
hold little interest for us. 
 
> Libsigc++ was written
> with a lot of portablity, 2.5 times the callbacks, several entire
> adaptor sets you don't even have.  Further, libsigc++ was
> optimizing for binary size and memory size at the expense
> of [source] code size.

The tradeoffs described above are exactly what we encourage for Boost.
 
> > - is exception safe,
> 
> Libsigc++ isn't intentionally exception unsafe.  If it
> has a problem it is fixable.

Can somebody point out any exception-unsafety in libsigc++?
 
> > - contains headers only, there is no need for linking,
> 
> This is by far more of a pitfall than a feature.  Libsigc++
> uses template factorization which pushes much of the code
> into a shared library.  Excessive inlining such as your proposal
> uses is quite bad.

Agreed, again.
 
> > - has no casts in the implementation,
> 
> No casts force virtuals into the library.  Where is it written
> that all good code shouldn't have any casting?  Casting is
> commonly used in templates to share internals and implementation
> and can be done safely and portably.

Casting within the implementation of a library is entirely 
permissible.  This is what abstraction is about: hiding the
ugly stuff in libraries.  It is a serious category error to 
introduce runtime inefficiencies in a low-level library just 
to make implementation prettier.
 
> > - uses standard library where appropriate,
> 
> By design libsigc++ depends on nothing, not even STL.  Since
> STL isn't used in many systems this is a feature.  If an when
> the quality of STL implementations rises to universal acceptance
> and use libsigc++ could be made to use it.  Also libsigc++ has
> polymorphic list elements which really can't be represented by
> STL, so much of it was necessary.

Independence from STL is definitely a feature in a low-level library.  
The STL containers make large assumptions about memory usage that are 
likely to be inappropriate in any particular case.  

The STL, properly, is a set of requirements lists describing how
to write iterators so they will work with standard algorithms.
A library that doesn't expose iteration in its interface has no 
appropriate relationship with the STL.
 
> (Libsigc++ is still working on a good rwlock which is needed to
> make it thread safe.)

Probably what would be interesting about such a rwlock implementation
would be its abstraction from any particular thread library.
(Unfortunately most rwlocks described in textbooks are not useful
because they allow writer starvation.)

Nathan Myers
ncm_at_[hidden]