Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-17 17:56:45


--- In boost_at_[hidden], Karl Nelson <kenelson_at_e...> wrote:
> > --- In boost_at_[hidden], Karl Nelson <kenelson_at_e...> wrote:
> > > > >
> > > > > on linux people use the defacto standard libsigc++
> > > > > http://libsigc.sourceforge.net/
> > >
> > >
> > > Libsigc++ is currently under going reconstruction to
> > > remove some of the overkill. However, as signals have to
> > > have a full type info, there will always be a requirement for
> > > a rather huge pile of templates.
> >
> > Are you one of the developers doing the reconstruction?
> > Collaboration of ideas, if not of code, may be benefit to both
> > efforts. Who knows, maybe even sharing/merging of code is in
order.
>
> I would be the one and only author of libsigc++. :-)
>
> Currently, I am trying to shave off the last few bytes
> in the interstructure and trying to make the functors
> sharable in some kind of threadsafe manner.

Then we really need to collaborate, at least with ideas ;). I want
callbacks for the Boost thread implementation, so obviously it must
be thread safe.

> > > Actually the m4 scripts are just used on unix to make the
sources
> > > because I hate typing. They aren't required unless you plan to
> > build
> > > your own templates for arguments more than what is provided.
> >
> > I realize that, but from a Boost perspective it still seems like
> > overkill. However, this was one of the more minor issues. It
was
> > just one that was easily conjured up from memory when I posted.
It's
> > been over a year since I looked at libsigc++. I've d/led the
library
> > once again to refresh myself, just to make sure there aren't some
> > issues addressed there that should be evaluated again here.
>
> I personally don't think that use of a preprocessor to produce
> the source of a library should be a consideration so long as
> the preprocessor is not a requirement of the platform doing the
> compilation. Use of a preprocessor like this is
> simply to improve the maintainence of the library thus when
> someone finds that I forgot to mark class after friend, I don't
> have to go through all the classes by hand.
> In other words I consider it a good thing.

The Boost libraries today are distributed as source only, so an m4
macro is a big consideration (though the distribution can contain pre-
generated source as you pointed out). I don't think anyone is
considering distributing binary packages.
 
> > As for libsigc++ and boost... until the owners come forth with a
> > desire to work with Boost I don't know how beneficial it is to
> > discuss some of the areas I think are overkill in it. It's an
> > excelent library in it's own right but I think it addresses
issues
> > different from our goals, so unless there was some joint efforts
I'm
> > not sure that's a good base for us to start from here.
>
> Well, I am the only author and have in the past discussed things
> with boost. It is currently a LGPL library, but I hold option
> and have signed X-style BSD copies of classes at request.
> My other libraries are being donated to Free Software Foundation,
> for which I am a strong supporter. I only consider boost
contributions
> when there is a strong community need for a common standard.
> I currently am short of time and when time becomes available
> will be submitting the previously discussed formating stream to
> boost.
>
> Hopefully, once sigc++ is simplified and made threadsafe I will
> submit it. Currently, I consider the code base too young
> to be ready for standardization.

Ok, then I'll start to address the issues I see in libsigc++ over
what we've been discussing.

First, libsigc++ is really a Signal/Slot implementation which isn't
quite the same thing as a callback. Signals/Slots are really a multi-
casting concept based on callbacks. The thread library isn't really
appropriate for Signals/Slots while it's very appropriate for
callbacks. I'd prefer to see the simpler Concept of Callback fleshed
out and implemented after which the Signal/Slot can be built on top
(or, if efficiency suggests so the implementation may be built
totally on it's own... it's just a seperate and distinct Concept to
me).

Second, if I'm not mistaken libsigc++ relies on a base class of
_Sig::Object, though it does use adapters and generators to hide this
in some circumstances. This is probably needed by libsigc++ to
handle such things as unregistering, but it seems heavy handed for
callbacks. (Note, this is probably an unfair criticism because we do
something very similar with the bridge pattern and external
polymorphism and it wouldn't take much to extend the concrete
implementation classes to include signal functionality. This might
even be an argument in favor of Doug Gregor's event() method.)

Third, use of a slot() generator appears to just be reduplication of
effort better handled by Lambda and other functor libraries. (Note,
this too may be an unfair criticism. Doug's event() method is no
different. It may be advantageous to have two such generators, one
to generate simple callbacks and the other to generate the callbacks
with additional functionality required for Signal/Slot useage. This
idea would require serious thought, however, to insure type safety
and compatibility.)

These are preliminary thoughts. I'll have to take a much closer look
at libsigc++ now. I'd be very interested in hearing your thoughts on
this. If we can come to some consensus here I may be of help to you
in adding thread safety to libsigc++ and in submitting the library to
Boost.

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk