On Sat, Sep 24, 2011 at 7:06 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Sat Sep 24 2011, Andrew Sutton <asutton.list-AT-gmail.com> wrote:
template< class T, class L, class U >
typename common_type< T const &, L const &, U const & >::type clamp(T const & x, L const & lower, U const & upper) { return x < lower ? lower : upper < x ? upper : x; }
for the use of common_type (assuming it accepts 3 parameters, which I seem to remember it did; if not, just nest); and something like
Can we please not define algorithms this way? It may be possible, but that doesn't mean its a good idea. I don't know how you could possibly prove that the algorithm preserves ordering (<) when the algorithm includes 5 possibly different types.
Thats not strictly true. I do know how you can prove it preserves ordering, but I'm not going to encourage the style.
Define it in terms of a single type and let conversions happen at the call type.
+1. The point is that you probably don't really understand what it means to order different types, and the theorems required to make it semantically well-founded are complicated enough that users of the algorithms won't be able to know whether they're using it properly.
I don't agree with this reasoning. If "you" (impersonal) don't really understand what it means to order objects of different types, why would you (or anyone else) define an operator< between objects of those types? Stated differently, I would think that the existence of an operator< comparing objects of different types implies (more often than not) an ordering between objects of those types. And if a user implicitly requests the use of this operator< through a call to clamp, I don't see why the interface should prohibit that. And regarding the 4-argument clamp, here we're replacing operator< with a user-provided comparison function object, so, again, I think it's appropriate to assume that the user knows what he or she is doing if comparing objects of different types. - Jeff