Re: [boost] Re: Signal/slot library

From: Tomasz Kowalczyk (tomek_at_[hidden])
Date: 2000-04-15 01:47:04

Nathan Myers wrote:
> [...]
> > 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.

I have thought that boost is not that much considered with
implementation. What is more important is semantics, elegant syntax and
complexity requirements.

> 
> > > - 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++?

Can you guarantee exception-safety of libsigc++ ? If no, then it has
serious implications for all programs using that library.

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

The matters are in fact more complicated. When you specify an interface
for a library you usually have to provide something called a reference
implementation. The reference implementation doesn't have to be
optimized, but it should closely follow the specs and should be
implemented in an understandable way. Reference implementation is
necessary for the implementors of optimized versions to understand main
concepts, key implementation techniques and to ensure uniform behavior.

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

I am not sure I can agree. Standard containers with default allocators
are much more likely to be optimized for particular platform and
compiler than your home-grown lists.

But of course, if there is a need to control how memory is managed, then
it should be a part of the library interface.

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

I did not say STL, but standard library. Apart from standard algorithms,
standard library contains also standard containers (which are much much
more widely used than algorithms) and many other things, and you should
know about it.

When mentioning standard library however, I was talking more about my
attempt to use STL functors (like bind1st<>, less<>, logical_or<> etc.)
to implement relational operations between signal arguments. These
functors are pretty much limited in their functionality, and I found
myself very proud of forcing them to work to some extent anyway :)

Tomek

> 
> > (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]
>