Re: Callbacks Again

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