on Mon Sep 26 2011, Andrew Sutton <asutton.list-AT-gmail.com> wrote:
Not necessarily. It depends whether N heterogeneous comparisons is going to be faster or slower than one conversion and N homogeneous comparisons. For all you know, each of the N heterogeneous comparisons actually forces the same conversion in the end, and it ends up being much slower.
Ah, yes. I hadn't considered that. Excellent point.
But most importantly, I know what "find a value in a sequence" means. I don't know what "find a value of one type in a sequence of another type" means... or at least I have to think really hard about it.
Exactly. What we need to do is convince people that if they aren't sure about the semantics of the operation, there's an app for that: find_if. Those higher-order overloads are there for a reason.
I agree with you.
Operators shouldn't be overloaded just for notational convenience.
...but I'm not sure the main point of this is about abuse of operator overloading.
Could be. I *don't* want to turn (what should be) EqualityComparable<T> into EqualityComparable<CommonType<T,U>::common_type> everywhere. Especially when U might turn out to be something like Iterator<I>::value_type.
It's actually worse than that. EqualityComparable<CommonType<T,U>::type> doesn't admit syntax for the comparison of T and U, only the CommonType, C.
Yes, exactly.
I think that the 0x formulation of concepts would have been such that, with that requirement, conversions to C would be generated even if overloads for T and U existed.
Yes it would have. -- Dave Abrahams BoostPro Computing http://www.boostpro.com