Re: Using std::less_equl predicate with std::min()
Stephan T. Lavavej [MSFT] <stl@microsoft.com> wrote:
There's a fundamental reason.
#1: When x is "smaller" than y, min(x, y) is required to return x.
#2: When x is "equivalent" to y, min(x, y) is required to return x.
#3: When x is "larger" than y, min(x, y) is required to return y.
For std::less-like predicates, there's a very simple implementation
that achieves this: return y < x ? y : x; and return pred(y, x) ? y :
x; for the generalized implementation.
Now suppose that min() allowed std::less_equal-like predicates.
return pred(y, x) ? y : x; doesn't work for std::less_equal (it
returns y for #2).
Ah, but Vladimir _wants_ it to return y for #2. He wants to use =
less_equal specifically for this purpose, trying to take advantage of an =
implementation detail. His complaint is about the debugging feature in =
MSVC STL implementation whereby less_equal is explicitly checked for and =
rejected (well, not specifically less_equal, but any predicate that =
violates strict weak ordering requirements).
Basically, his argument is that, instead of mandating that min() return =
the smaller of the two elements, the standard should have just stated =
that min(x, y, pred) returns (pred(y, x) ? y : x). Then std::less and =
std::less_equal would behave the way he wants (but not necessarily the =
way that obeys the principle of least surprise).
It's not quite clear how min_element should be specified in this new =
world, nor what restrictions should be placed on the predicate passed to =
it.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not =
necessarily a good idea. It is hard to be sure where they are going to =
land, and it could be dangerous sitting under them as they fly overhead. =
-- RFC 1925