Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at