On Sun, Sep 25, 2011 at 3:55 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 09/25/2011 03:26 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Sun, Sep 25, 2011 at 3:15 PM, Steven Watanabe <watanabesj@gmail.com wrote:
Precondition: operator< defines an ordering on objects of type U. For any
2 objects a and b of types A and B, respectively, where A and B are each one of {T,L,H}, a < b is equivalent to (U)a < (U)b. !(hi < lo).
This should be !(U(hi) < U(lo)).
Equivalent, given the preconditions, no?
Your restrictions on the comparison are
too strict. You don't want to constrain (lo < lo), (hi < hi), (hi < lo), or (lo < hi), because that would exclude T = std::string, L = H = const char*.
I don't follow. - (lo < lo) and (hi < hi) should both return false, so that clamp(x, x, hi) and clamp(x, lo, x) both return x. I think this is desirable.
Sorry. I was actually thinking in terms of the types, rather than the actual values.
- I think !(hi < lo) is a reasonable precondition so that the result is independent of whether you first compare to lo or hi.
I agree, the only question is how to express it.
How do these preconditions exclude T == std::string and L == H == char const *? Doesn't the STL define comparison operators between these types that do the "obvious" thing?
Comparing const char*'s compares the pointers, not the contents.
Ah, there's the rub. I missed that. Now I'm troubled that certain mixes of std::string and char const * would be bad if operator< were used by default: clamp("x", "L", std::string("H")) // bad clamp(std::string("x"), "L", "H") // okay, assuming current implementation...and no asssertion that !(hi < lo) - Jeff