Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2004-03-11 10:10:40

On Thursday 11 March 2004 06:19 am, Peter Dimov wrote:
> Douglas Gregor wrote:
> > On Wednesday 10 March 2004 07:41 am, Peter Dimov wrote:
> >> Douglas Gregor wrote:
> >>> I'd think that this is the right expectation for Lambda, but not for
> >>> FC++ or Bind. Not that I'm helping any :)
> >>
> >> No, I don't think so. Expressions that are valid for both Bind and
> >> Lambda should have the same semantics. And in fact, this is not just
> >> theory:
> >
> > Having Lambda's == and != operators return function objects
> > convertible to bool would keep Lambda's semantics a superset of
> > Bind's semantics.
> I find your suggestion intriguing and appealing, in a certain "clever hack"
> way, but you miss my point. I am not talking about keeping Lambda
> compatible with what Bind does now. What I have in mind is an extended Bind
> that supports !bind, bind ==, bind !=. That Bind is what I want to be
> compatible with Lambda. At the moment, your idea seems too costly to
> implement in Bind, and I see no corresponding benefits, but I'll keep it in
> mind as a potential alternative.

It's not really an alternative. We have two possible reasons that a binding
operator would want to overload operator==: for comparison or for creating a
function object. I'm just saying we don't have to choose between the
alternatives, because we can overload operator== to return a function object
that also has a conversion to bool that compares the stored function objects.

The benefit is that we don't need to introduce a "function_equal" to compare
functions and we can still choose whether to support
        (bind(f, _1) == bind(g, _1))(5)


Boost list run by bdawes at, gregod at, cpdaniel at, john at