From: Karl Nelson (kenelson_at_[hidden])
Date: 2000-11-17 17:13:13
> --- 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.
> > > I'm familiar with libsigc++ from a high level stand point (looked
> > > the documentation and code, but don't have real experience in
> > > it). This library is a tad bit of overkill, IMHO, and I'm not
> > > that the implementation is appropriate for Boost. For instance,
> > > makes use of m4 scripts during building of the library and the
> > 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
> > 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.
> > > library contains a LOT of code to deal with binding issues that,
> > > again, I feel are best left to libraries such as Lambda.
> > I am not really familar with Lambda. Is there docs on
> > it? When I stated libsigc++ I was looking for a good
> > library to do function casting, but nothing I found was
> > that portable. The templates provided a decent balance.
> The Lambda Library is in the files archive here, with docs. There's
> a newer library available elsewhere, I believe, and I know that the
> authors are working on enhancements/changes right now before
> officially submitting it to Boost.
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk