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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk