Re: [boost] [Review:Algorithms] Order of args to clamp

Subject: Re: [boost] [Review:Algorithms] Order of args to clamp
From: Andrew Sutton (asutton.list_at_[hidden])
Date: 2011-09-26 13:08:44

> 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.
Operators shouldn't be overloaded just for notational convenience.

> 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. 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.