The Orderable concept represents totally ordered data types.
Intuitively, Orderable objects must define a binary predicate named less returning whether the first argument is to be considered less than the second argument. The word "total" means that distinct objects must always be ordered; if a and b are not equal, then exactly one of less(a, b) and less(b, a) must be true. This is a contrast with weaker kinds of orders that would allow some objects to be incomparable (neither less than nor greater than). Also note that a non-strict total order may always be obtained from a strict total order (and vice-versa) by setting
The non-strict version is used in the description of the laws because it makes them easier to parse for humans, but they could be formulated equivalently using the strict order.
less
When less is defined, the other methods are defined from it using the same definition as mandated in the laws below.
Rigorously speaking, a total order <= on a set S is a binary predicate \( <= \;: S \times S \to bool \) such that for all a, b, c in S,
Additionally, the less, greater and greater_equal methods should have the following intuitive meanings:
Comparable (free model)Orderable requires less_equal to be a total order, a model of Comparable may always be obtained by setting hana::integral_constant, hana::optional, hana::pair, hana::string, hana::tuple
Two data types T and U that model the cross-type version of the usual LessThanComparable C++ concept are automatically a model of Orderable by setting
The cross-type version of the LessThanComparable concept is analogous to the cross-type version of the EqualityComparable concept presented in N3351, which is compatible with the usual single type definition. However, note that the LessThanComparable concept only requires < to be a strict weak ordering, which is a weaker requirement than being a total order. Hence, if less is used with objects of a LessThanComparable data type that do not define a total order, some algorithms may have an unexpected behavior. It is the author's opinion that defining operator< as a non-total order is a bad idea, but this is debatable and so the design choice of providing a model for LessThanComparable data types is open to debate. Waiting for some user input.
Let A and B be two Orderable data types. A function \( f : A \to B\) is said to be order-preserving (also called monotone) if it preserves the structure of the Orderable concept, which can be rigorously stated as follows. For all objects x, y of data type A,
Another important property is that of being order-reflecting, which can be stated as
We say that a function is an order-embedding if it is both order-preserving and order-reflecting, i.e. if
The comparison methods (less, less_equal, greater and greater_equal) are "overloaded" to handle distinct data types with certain properties. Specifically, they are defined for distinct data types A and B such that
A and B share a common data type C, as determined by the common metafunctionA, B and C are all Orderable when taken individuallyis_embedding metafunction.The method definitions for data types satisfying the above properties are
The less, greater, less_equal and greater_equal methods can be called in two different ways. First, they can be called like normal functions:
However, they may also be partially applied to an argument as follows:
Take good note that the order of the arguments is reversed, so for example less.than(x)(y) is equivalent to less(y, x), not less(x, y). This is because those variants are meant to be used with higher order algorithms, where the chosen application order makes sense.
Variables | |
| constexpr auto | boost::hana::greater |
Returns a Logical representing whether x is greater than y. More... | |
| constexpr auto | boost::hana::greater_equal |
Returns a Logical representing whether x is greater than or equal to y. More... | |
| constexpr auto | boost::hana::less |
Returns a Logical representing whether x is less than y. More... | |
| constexpr auto | boost::hana::less_equal |
Returns a Logical representing whether x is less than or equal to y. More... | |
| constexpr auto | boost::hana::max |
Returns the greatest of its arguments according to the less ordering. More... | |
| constexpr auto | boost::hana::min |
Returns the smallest of its arguments according to the less ordering. More... | |
| constexpr auto | boost::hana::ordering |
Returns a function performing less after applying a transformation to both arguments. More... | |
|
constexpr |
#include <boost/hana/fwd/greater.hpp>
Returns a Logical representing whether x is greater than y.
Given a Logical Bool and two Orderables A and B with a common embedding, the signature is \( \mathrm{greater} : A \times B \to Bool \).
| x,y | Two objects to compare. |
|
constexpr |
#include <boost/hana/fwd/greater_equal.hpp>
Returns a Logical representing whether x is greater than or equal to y.
Given a Logical Bool and two Orderables A and B with a common embedding, the signature is \( \mathrm{greater\_equal} : A \times B \to Bool \).
| x,y | Two objects to compare. |
|
constexpr |
#include <boost/hana/fwd/less.hpp>
Returns a Logical representing whether x is less than y.
Given a Logical Bool and two Orderables A and B with a common embedding, the signature is \( \mathrm{less} : A \times B \to Bool \).
| x,y | Two objects to compare. |
|
constexpr |
#include <boost/hana/fwd/less_equal.hpp>
Returns a Logical representing whether x is less than or equal to y.
Given a Logical Bool and two Orderables A and B with a common embedding, the signature is \( \mathrm{less\_equal} : A \times B \to Bool \).
| x,y | Two objects to compare. |
|
constexpr |
#include <boost/hana/fwd/max.hpp>
Returns the greatest of its arguments according to the less ordering.
min for details.
|
constexpr |
#include <boost/hana/fwd/min.hpp>
Returns the smallest of its arguments according to the less ordering.
x < y or not. If we wanted to be mathematically correct, we should probably ask that if_(cond, x, y) returns a common data type of x and y, and then the behavior of min would follow naturally. However, I'm unsure whether this is desirable because that's a big requirement.
|
constexpr |
#include <boost/hana/fwd/ordering.hpp>
Returns a function performing less after applying a transformation to both arguments.
ordering creates a total order based on the result of applying a function to some objects, which is especially useful in conjunction with algorithms that accept a custom predicate that must represent a total order.
Specifically, ordering is such that
or, equivalently,
Orderable concept.Given a Logical Bool and an Orderable B, the signature is \( \mathrm{ordering} : (A \to B) \to (A \times A \to Bool) \).