Re: Callbacks Again

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-17 18:03:36

--- In boost_at_[hidden], Jesse Jones <jejones_at_a...> wrote:
> >--- In boost_at_[hidden], Douglas Gregor <gregod_at_r...> wrote:
> >> On Fri, 17 Nov 2000 19:40:05 -0000
> >> 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).
> 
> My (and I think William's version) handle free functions in the 
same way as
> functors are handled. Member functions need a bit more. I think 
they should
> be rolled into the core callback code, but William is so far 
unpersuaded.

I think functors handle this.  Every functor library has a way to 
generate a "closure" form of functor.  It seems wrong to duplicate 
effort, especially when libraries specifically designed to addresss 
this are likely to do a better job of it.  However, I'm not hard 
nosed about it, so give counter arguments for why they should be 
addressed.
 
> >> 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.
> 
> Yep (of course a const void* conversion would be better than bool).

Would it?  Didn't we decide the opposite for boost::any?
 
> >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.
> 
> It's not a "tremendous amount of effort". :-) It's a bit tedious, 
but it
> falls out very naturally from the code I posted.

I think we're crossing wires here.  A closure is simple to implement, 
at least minimally.  However, libraries like Lambda do a better job 
than the "minimalist" approach, and if you've looked at their 
implementation you must agree that they are a "tremendous amount of 
effort" :).

Bill Kempf