From: Douglas Gregor (gregod_at_[hidden])
Date: 2004-03-11 16:25:00
On Thursday 11 March 2004 10:27 am, Peter Dimov wrote:
> Douglas Gregor wrote:
> > 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)
> But there's still the implicit assumption that not introducing
> function_equal is a benefit. I don't see why this should be so clear cut.
> What particular problems do you see with function_equal?
I don't use string_equal for strings or shared_ptr_equal for shared_ptr's, so
why should I do so for function objects? Function objects are objects, they
just happen to have a function call operator. The only reason I can see for
us avoiding using operator== is that Lambda has already hijacked this
operator for something entirely different. That doesn't seem like a great
reason to force everyone else using other libraries to use "function_equal"
instead of the more natural operator==.
We're only allowing bind(...) == bind(...) when the types are equivalent,
right? So we're only realy worried about the very, very narrow case where we
have lambda-expr-1 == lambda-expr-2 and the two operands have exactly the
same type. We have a way to deal with this case using an implicit conversion
to bool, so why does it weigh so heavily on our minds? Or is there another
reason to avoid operator==?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk