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

Subject: Re: [boost] [Review:Algorithms] Order of args to clamp
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-09-26 14:14:54

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