Boost logo

Boost :

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

On Sat, Sep 24, 2011 at 7:06 PM, Dave Abrahams <dave_at_[hidden]> wrote:

> on Sat Sep 24 2011, Andrew Sutton <> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at