Re: Callbacks Again

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-17 14:40:05

--- In boost_at_[hidden], Douglas Gregor <gregod_at_r...> wrote:
> On Thu, 16 Nov 2000 22:35:29 -0000
> "William Kempf" <sirwillard_at_m...> wrote:
> 
> [snip]
> > So... before we discuss the thread specific stuff I'd like to 
first 
> > address callbacks.  I've read all the articles on the subject 
that I 
> > can get my hands on and it seems they all take different 
approaches 
> > (the Kubrick article covers several of them), each with varying 
pros 
> > and cons.  I'd like to describe what requirements I think our 
version 
> > of callbacks need to take just to make sure everyone agrees with 
my 
> > opinions before we attempt to create an actual implementation.
> > 
> > 1.  Need to allow traditional functor types as the callback so 
that 
> > function pointers, standard functors, hand coded functors and 
Lambda 
> > Library style functors can all be used with relative ease.
> > 2.  The callback type(s) should be templatized on the return type 
and 
> > argument types, but not on the functor type to simplify useage.
> > 3.  Copying a callback should be quick, on par with copying a 
> > function pointer.  This is not gauranteed with functors but 
becomes 
> > somewhat important with callbacks that may be stored, copied and 
> > passed around frequently in some cases.
> > 4.  A callback should itself be a functor.
> > 5.  Compiler type coercion should be possible to apply to the 
functor 
> > that the callback wraps for all parameters and the return value.
> > 6.  Executing a callback should be nearly as efficient as 
executing 
> > the contained functor.
> [snip]
> 
> I've written a small library
> (http://www.cs.rpi.edu/~gregod/blackrock/blackrock-0.2.1.tar.gz) 
> which already fulfills all requirements except for #3 (due to 
> memory allocations in the copy). I'll Boostify and submit it if 
> there is sufficient interest. In the library, I referred to 
> callback as "events", so consider the terms interchangeable for now 
> and I would happily change the terminology during Boostification. 
> Now to a library usage summary:

Thanks.  It will take me a while to evaluate this because of the 
amount of code involved (mostly repetition because of the number of 
parameters acceptable).  The code I posted is easier to decipher, so 
if you've got time you might help everyone out by detailing what you 
see the differences as.  I'll take a crack at what was obvious to me:

Both implementations use the Bridge pattern to achieve External 
Polymorphism.  However, your implementation both derives from and 
includes a pointer to a "base/impl" class.  I'm not sure this is 
needed, or even necessarily a good idea.

Your implementation uses the Clone pattern to implement copy and 
assignment.  This is what results in your implementation not 
fullfilling requirement #3.  My/Jesse's implementation uses a 
reference counting mechanism instead (in fact the working 
implementation I've currently got in Threads uses a hacked version of 
boost::shared_ptr which is thread safe).  For efficiency reasons I 
think this is the better implementation, but right now I'm also 
wondering if this might cause some unforseen issues as well.

Your implementation uses a single class for "callbacks" with some 
template arguments defaulted to a utility Unused class.  This is a 
similar idea to how tuples are implemented and is worth considering 
as an alternative to multiple class definitions for callbacks of 
different numbers of arguments.

That's the obvious stuff I see.  Care to provide a better comparison 
summary?

Bill Kempf