Exit Zen
13
:66
English
Overloads of `tag_invoke` called by <<ref_value_from>> take the form:
69/690 · 69
13
:83
English
For the complete listing of all available member functions and nested types, see the reference page for <<ref_object>>.
66/1190 · 119
13
:46
English
The member function <<ref_value_kind,`value::kind`>> may be used to query the kind stored in the value. Alternatively, member functions like <<ref_value_is_object,`value::is_object`>> <<ref_value_is_number,`value::is_number`>> may be used to check whether or not the value is a particular kind:
293/2940 · 294
14
:36
English
A special variant which can hold one of any of the six standard JSON data
34/730 · 73
14
:86
English
As with `std::pair`, the <<ref_key_value_pair>> type can be used with structured bindings in {cpp}17. Specializations of `std::tuple_size`, `std::tuple_element`, and overloads of <<ref_get>> are all provided for this purpose.
172/2250 · 225
14
:57
English
Functions like <<ref_value_if_object,`value::if_object`>> actually return a pointer to the object if the value is an object, otherwise they return null. This allows them to be used both in boolean contexts as above, and in assignments or conditional expressions to capture the value of the pointer:
161/2980 · 298
14
:35
English
of JSON texts each contained in a single contiguous character buffer, returning each result as a <<ref_value>>.
74/1110 · 111
15
:72
English
While overloads of `tag_invoke` called by <<ref_value_to>> take the form:
65/730 · 73
15
:67
English
After a <<ref_value>> is constructed, its kind can change depending on what is assigned to it, or by calling functions such as <<ref_value_emplace_array,`value::emplace_array`>> or <<ref_value_emplace_bool,`value::emplace_bool`>>. If the assignment is successful, in other words it completes without any exceptions then the value is replaced. Otherwise, the value is unchanged. All operations which can fail to modify a value offer the strong exception safety guarantee.
326/4700 · 470
15
:42
English
The <<ref_serialize>> function converts a <<ref_value>> into a {std_string}:
95/760 · 76
16
:100
English
Often it is needed to use several conversion contexts together. For example, consider a log of remote users identified by IP addresses accessing a system. We can represent it as `std::vector<std::pair<std::chrono::system_clock::time_point, ip_address>>`. We want to serialize both ``ip_address``es and ``time_point``s as strings, but for this we need both `as_string` and `as_iso_8601` contexts. To combine several contexts just use {std_tuple}. Conversion functions will select the first element of the tuple for which a `tag_invoke` overload exists and will call that overload. As usual, `tag_invoke` overloads that don't use contexts and library-provided generic conversions are also supported. Thus, here's our example:
396/7230 · 723
16
:93
English
When an <<ref_object>> is formatted to a {std_ostream}, the result is a valid JSON. That is, the object will be output with curly braces and a comma separated list of key/value pairs, as per the JSON specification.
109/2140 · 214
16
:80
English
The following table shows all of the ways to determine and access the contents of a <<ref_value>>:
53/980 · 98
16
:102
English
Workarounds for this problem are worse than the problem itself. The library could return a pair with the vector and `std::unique_ptr<std::pmr::memory_resource>` which the caller must manage. Or the library could change its function signatures to accept a {ref_memory_resource}``*`` provided by the caller, where the library also makes public the desired memory resources (`my_resource` above).
212/3930 · 393
16
:49
English
In situations where serializing a <<ref_value>> in its entirety is inefficient or even impossible, <<ref_serializer>> can be used to serialize a <<ref_value>> incrementally. This may be done for a variety of reasons, such as to avoid buffering the entire output, or to ensure that a fixed amount of work is performed in each cycle. Instances of <<ref_serializer>> maintain an output state using internal dynamically allocated structures, with an interface to retrieve successive buffers of the serialized output into a caller provided buffer. Here is an example, demonstrating how <<ref_operator_lt_lt>> may be implemented using a <<ref_serializer>>:
349/6500 · 650
17
:40
English
of JSON texts incrementally, returning each result as a <<ref_value>>.
51/700 · 70
17
:64
English
As with the parser, the serializer may be reused by calling <<ref_serializer_reset>>. This sets up the object to serialize a new instance and retains previously allocated memory. This can result in performance improvements when multiple variables are serialized.
121/2620 · 262
18
:58
English
https://nlohmann.github.io/json/classnlohmann_1_1basic__json_ab330c13ba254ea41fbc1c52c5c610f45.html[`json::parse`], which uses the default `std` allocator, and is designed for general use including mutation of the document after it is parsed. This library does not provide an interface to reuse temporary storage used during parsing or serialization on subsequent operations. |===
204/3800 · 380
18
:61
English
The result is created via <<ref_value_to_number>>.
60/500 · 50
19
:123
English
As was shown previously, generic conversions provided by the library forward contexts to conversions of nested objects. And in the case when you want to provide your own conversion function for a composite type enabled by a particular context, you usually also need to do that.
72/2770 · 277