Re: Callbacks Again

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

--- In boost_at_[hidden], Jesse Jones <jejones_at_a...> wrote:
> >> >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.
> >>
> >> I'd go with allowing callbacks to be constructed with either a
> >functor or
> >> an object/member function pointer. The second is probably
> >redundant, but
> >> it's such a common operation that it should be very easy to do.
> >
> >mem_fun, LL et. al. take care of the object/member function 
pointer,
> >so it's redundant IMHO.
> 
> mem_fun won't quite cut it. For a method call it requires that the 
object
> be passed in as you call the callback. This means that you can't 
call
> arbitrary callbacks from non-template code. Very bad.

That's what binders, like std::bind1st, are for.  Granted, the 
standard library falls way short in this area, thus the need for 
Lambda and it's competitors.  However, for simple things the standard 
library suffices.

> >> We probably also want to be able to test for equality. Possibly
> >ordering as
> >> well.
> >
> >Hmmm... interesting idea, but I'm not so sure about that.  You 
can't
> >compare functors created with the standard library, for instance.
> >And ordering makes little sense, unless it's a partial ordering, 
like
> >that provided by std::type_info.  Comparison and ordering are going
> >to be hard nuts to crack here given that standard functors don't
> >support this.
> 
> Hickey's original library included ordering, but I've never used 
it. I'm
> not sure I've even used equality tests although that seems more 
useful.

It seems to be, but with generated functors I'm not sure it makes 
sense.  How would you compare two functors generated using the 
standard library?

> >It's best handled by other
> >libraries such as the standard library and LL, since such libraries
> >can do a better job of addressing the issue than we're likely to do
> >in this specialized case.
> 
> The standard library isn't good enough because it's highly 
desirable to
> call the callbacks from non-template code. I'm not sure about the 
LL, but
> one obvious objection is that it's less portable than some bind 
functions
> targeted at just callback objects.

I'm not sure what you mean by "non-template" code.  The standard 
library allows you to generate functors that can be used with non-
templated code, though said functors and the generation require 
templates.  However, generators make this trivial even for those not 
versed in template syntax.  LL is no different, it just addresses the 
real issues with the standard library:  allows arbitrary number of 
parameters (the standard is limited to unary and binary functors), 
handles parameter conflicts such as reference to reference problems, 
provides a more intuitive interface for generating functors through 
lambda expressions, etc.