* docs: state that NaN ordering inside containers depends on the standard When the element-wise comparison of arrays or objects reaches a NaN and a number (or another NaN) before any other difference, the result depends on the language standard. Before C++20 the pair counts as equivalent and the following elements (or the sizes) decide, so [1] <= [NaN] is true. Since C++20 the comparison is unordered and <, <=, >, >= all yield false. Document this on operator<, <=, >, >= and <=>. Signed-off-by: Niels Lohmann <mail@nlohmann.me> * docs: fix the FILE* notes of parse() and the locking promise The performance note of parse() said a FILE* is read one character at a time. With glibc and the Apple C library the characters in the FILE's buffer are scanned in bulk; only elsewhere is it one character at a time. The file is locked once only where the C library has unlocked stdio functions (not on musl, MinGW, newlib, with JSON_DISABLE_UNLOCKED_FILE_IO, or under MSan). Qualify the promise on parse.md, sax_parse.md, the parsing page and the performance page. Signed-off-by: Niels Lohmann <mail@nlohmann.me> * docs: fix integer ranges in the MessagePack and BJData tables number_integer_t is std::int64_t, so number_integer cannot hold values above 9223372036854775807; those are number_unsigned. The MessagePack row for uint 64 listed the range up to 18446744073709551615, and the BJData table had a uint64 row for number_integer that can never be selected. The CBOR table was already corrected. Signed-off-by: Niels Lohmann <mail@nlohmann.me> * docs: name the macros that turn off FILE* locking and bulk scans parse() and sax_parse() now say that the FILE* is locked unless JSON_DISABLE_UNLOCKED_FILE_IO is defined to 1, and the input-source table and the performance page name JSON_DISABLE_STREAM_BULK_SCAN and JSON_DISABLE_UNLOCKED_FILE_IO with what each turns off. Signed-off-by: Niels Lohmann <mail@nlohmann.me> --------- Signed-off-by: Niels Lohmann <mail@nlohmann.me>
4.0 KiB
4.0 KiB
nlohmann::basic_json::operator<
// until C++20
bool operator<(const_reference lhs, const_reference rhs) noexcept; // (1)
template<typename ScalarType>
bool operator<(const_reference lhs, const ScalarType rhs) noexcept(/* see below */); // (2)
template<typename ScalarType>
bool operator<(ScalarType lhs, const const_reference rhs) noexcept(/* see below */); // (2)
-
Compares whether one JSON value
lhsis less than another JSON valuerhsaccording to the following rules:- If either operand is discarded, the comparison yields
#!cpp false. - If both operands have the same type, the values are compared using their respective
operator<. - Integer and floating-point numbers are compared by their exact values, without converting the integer to
floating-point. For instance,
9007199254740992.0is less than9007199254740993. - In case
lhsandrhshave different types, the values are ignored and the order of the types is considered, which is:- null
- boolean
- number (all types)
- object
- array
- string
- binary For instance, any boolean value is considered less than any string.
- If either operand is discarded, the comparison yields
-
Compares whether a JSON value is less than a scalar or a scalar is less than a JSON value by converting the scalar to a JSON value and comparing both JSON values according to 1.
Template parameters
ScalarType- a scalar type according to
std::is_scalar<ScalarType>::value
Parameters
lhs(in)- first value to consider
rhs(in)- second value to consider
Return value
whether lhs is less than rhs
Exception safety
- No-throw guarantee: this function never throws exceptions.
- No-throw guarantee if converting the scalar to a JSON value cannot throw, as for numbers, Booleans, and
#!cpp nullptr; the function is#!cpp noexceptexactly in that case. Otherwise, it throws what the conversion throws, for examplestd::bad_allocwhen converting a string, orout_of_range.410for an enum value not mapped byNLOHMANN_JSON_SERIALIZE_ENUM_STRICT.
Complexity
Linear.
Notes
!!! note "Comparing NaN"
`NaN` values are unordered within the domain of numbers.
The following comparisons all yield `#!cpp false`:
1. Comparing a `NaN` with itself.
2. Comparing a `NaN` with another `NaN`.
3. Comparing a `NaN` and any other number.
For arrays and objects, the elements are compared in order. If the comparison reaches a `NaN` and a number (or
another `NaN`) before any other difference, the result depends on the language standard. Before C++20, the pair
counts as equivalent and the following elements (or the sizes) decide: for instance, `[NaN] < [1, NaN]` and
`[1] <= [NaN]` are `#!cpp true`. Since C++20, the whole comparison is unordered, and `<`, `<=`, `>`, and `>=` all
yield `#!cpp false`. Otherwise (for example `[1, NaN] < [2, NaN]`, or objects whose keys differ), the result is the
same for all language standards. The same program can therefore order such values differently when it is compiled
with a different language standard.
!!! note "Operator overload resolution"
Since C++20 overload resolution will consider the _rewritten candidate_ generated from
[`operator<=>`](operator_spaceship.md).
Examples
??? example
The example demonstrates comparing several JSON types.
```cpp
--8<-- "examples/operator__less.cpp"
```
Output:
```json
--8<-- "examples/operator__less.output"
```
See also
operator<=>- comparison: 3-way
Version history
- Added in version 1.0.0. Conditionally removed since C++20 in version 3.11.0.
- Added in version 1.0.0. Conditionally removed since C++20 in version 3.11.0.
Made conditionally
#!cpp noexceptin version 3.13.0; before, a throwing conversion calledstd::terminate.