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

Subject: Re: [boost] [Review:Algorithms] Order of args to clamp
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-09-25 18:04:37

On Sun, Sep 25, 2011 at 10:09 AM, Andrew Sutton <asutton.list_at_[hidden]>wrote:

> >> No, no, no.  Sorry to be so hard-line about this, but no.
>
> > So the cost of the extra char*-to-string conversions with the 1-type
> version
> > of clamp increases the execution time of that function by more than 3X.
>
> > Personally, I value that performance benefit above the easier-to-describe
> > semantics that you want.
>
> I keep implying there's a middle ground. I guess I'll be more explicit.
>

Well, it didn't sound like that's the position you originally took,
so...thanks for being more explicit.

> Every example given in this thread where different types should be
> comparable are related (or should be related) through common type:
>

Naturally.  If they didn't have a common_type, you couldn't make a sensible
return type anyway, so as far as I've been concerned, that's been the
premise.

- int and double
> - types with different Allocators (should be)
> - std::duration with different Periods
> - const char* and string
> You can map semantics of operations on these different types to their
> common type, and still be able to reason about the correctness of the
> algorithm.
>
> That means you could have an algorithm that takes different types with
> a requirement that they share a common type. You get the performance
> gains from your previous example, and you get the correctness that we
> should expect from Boost libraries.
>
> If you want to compare unrelated types, use a version of the algorithm
> not written in terms of <.
>

I don't think anyone ever wanted to compare *unrelated* types, just
*different* types.

- Jeff