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