From: Douglas Gregor (gregod_at_[hidden])
Date: 2004-03-11 17:58:40
On Thursday 11 March 2004 04:37 pm, Peter Dimov wrote:
> Douglas Gregor wrote:
> > 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?
> Wait a minute. Which "I" are we speaking of here? function<> will use
> function_equal, but the end users will not be required to even know about
> its existence. If they want to define operator== for their function objects
> and then compare them for equality, they are perfectly welcome.
"I" as a user, that wants to compare two function objects that are, say,
returned from bind.
Anyway, I'm going to back off on this. We'll define function_equal to (by
default) use operator==, and overload it for bind/lambda/fc++/mem_fn/etc.
function objects to do the actual comparison.
Function's operator== (or contains, or whatever survives the discussion in our
other thread) will use function_equal.
If users are clamoring for the ability to compare function objects returned by
bind and whining about using function_equal, we can revisit it down the road.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk