Re: [boost] Re: Callbacks Again

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 
> at 
> > > the documentation and code, but don't have real experience in 
> using 
> > > it).  This library is a tad bit of overkill, IMHO, and I'm not 
> sure 
> > > that the implementation is appropriate for Boost.  For instance, 
> it 
> > > 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 
> 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.

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

--Karl