Boost logo

Boost :

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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at