Re: Callbacks Again

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-17 15:54:33

--- In boost_at_[hidden], Douglas Gregor <gregod_at_r...> wrote:
> On Fri, 17 Nov 2000 19:40:05 -0000
> 1) I use one "Callback" class that takes any number of parameters
>   instead of having many Callback0, Callback1, ..., CallbackN 
>   classes.

In theory I really like this.  Unfortunately, it requires partial 
template specialization and so may hinder or prevent implementation 
on VC++, which I think is a major problem.  It's definately an idea 
worth looking into, however.
 
> 2) I provide a conversion to bool so that we can check if a given
>   callback has a target. This allows us to more easily create 
>   functions where an outside user can (optionally) change some
>   behavior of the function at runtime. For instance, we may want
>   a system where the user can change (at runtime) the computation
>   of the norm of two vectors within some algorithm. Then we can
>   define a callback:
> 	Callback< float, Vector<float>, Vector<float> > 
> 	  calculateNorm;
> 
>   // Then, when we need the norm
>   float norm; Vector<float> u, v;
>   if (calculateNorm)
>     norm = calculateNorm(u,v); // user calculates the norm
>   else
>     norm = innerprod(u,v); // Default to the inner product

Yes, this is a good idea and is trivial to add to the implementation 
I posted.

> 3) I have explicit classes (each derived from EventBase) which
>   allow callbacks to member functions, free functions or
>   functors. It appears that the William Kempf and Jesse Jones'
>   solution would use only functors (relying on another library 
>   (the lambda library?) to build functors out of free/member
>   functions). This makes it tougher to include the bool 
>   conversion (how do we know if a functor has a real target or 
>   not?), which I consider essential.

The bool conversion can be handled by inclusion of a default 
constructor that sets the "impl" pointer to null.  The actual functor 
is an internal detail that does not effect this in any way.  I find 
it useful to leave things as they are in our implementation in order 
to not duplicate the effort of creating functors yet again.  There 
are already numerous libraries available for doing this, including 
the standard library that comes with every compiler.  Libraries such 
as Lambda do a much better job of this than we could possibly do with 
out duplicating a tremendous amount of effort, and with no clear 
benefit.
 
> 4) I provide an "event" helper function which builds an 
>   appropriate event object given the operands. Granted, this is
>   not very useful if #3 isn't considered useful.

Right.  The constructor for the callback is enough here so long as 
we're in agreement about #3.  Hopefully I made enough of a case in my 
response to #3 to at least spark detailed debate if not enough to win 
you over completely.

Bill Kempf