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
>> 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
> 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.
Yes it would have.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk