On Sun, Sep 25, 2011 at 10:09 AM, Andrew Sutton <asutton.list@gmail.com>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