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
> >> >function pointers, standard functors, hand coded functors and
> >> >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
> >so it's redundant IMHO.
> mem_fun won't quite cut it. For a method call it requires that the
> be passed in as you call the callback. This means that you can't
> 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
> >> 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
> >compare functors created with the standard library, for instance.
> >And ordering makes little sense, unless it's a partial ordering,
> >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
> not sure I've even used equality tests although that seems more
It seems to be, but with generated functors I'm not sure it makes
sense. How would you compare two functors generated using the
> >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
> call the callbacks from non-template code. I'm not sure about the
> one obvious objection is that it's less portable than some bind
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk