Topic: std::max returning the first argument when the arguments are equivalent


Author: Seungbeom Kim <musiphil@bawi.org>
Date: Thu, 27 Jan 2011 00:54:12 CST
Raw View
Alexander Stepanov says in Lecture 7 of his "Notes on Programming" that,
for stability, "max should return the first object only when it is
strictly greater than the second."

On the other hand, 25.3.7 [lib.alg.min.max] specifically mandates that
std::max return the first argument when the arguments are equivalent.
Why does it do that? What additional benefit does it bring?
It could have been left unspecified, so I believe there was a reason
for this additional specification.

--
Seungbeom Kim


[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]





Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@googlemail.com>
Date: Fri, 28 Jan 2011 01:07:32 CST
Raw View
On 2011-01-27 07:54, Seungbeom Kim wrote:
>
> Alexander Stepanov says in Lecture 7 of his "Notes on Programming" that,
> for stability, "max should return the first object only when it is
> strictly greater than the second."
>
> On the other hand, 25.3.7 [lib.alg.min.max] specifically mandates that
> std::max return the first argument when the arguments are equivalent.
> Why does it do that? What additional benefit does it bring?
> It could have been left unspecified, so I believe there was a reason
> for this additional specification.

It was clear from begin with that std::min and std::max were required
to specify the return value ordering, because this information is
essential for many user-defined types and in some rare situations for
fundamental types as well (E.g. whether std::max(-0.0, 0.0) would
return the the signed or unsigned zero).

As Stepanov also mentions in his book "Elements of Programming", the
decision to specify the order of max as done in the existing standard
library, was a design defect by himself in his ancestor library (an
oversight, so to say).

The problem is that the existing specification is now in the wild
since ages and there is basically no chance to fix it without taking
the risk to break a lot of code that relies on the spec of the
standard. The optimum solution - as quoted above - would make std::max
a stable algorithm (std::min does already satisfy this criterion), but
the advantage of the optimum specification doesn't really weight its
disadvantages (breaking existing code), so I don't expect either a
change of the spec nor the addition of something like std::stable_max
- but who knows... ;-)

HTH & Greetings from Bremen,

Daniel Kr   gler



--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]