Exit Zen
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
20
:128
English
Consider this example. As was discussed in a previous section, <<ref_is_map_like>> requires that your key type satisfies <<ref_is_string_like>>. Now, let's say your keys are not string-like, but they do convert to <<ref_string>>. You can make such maps to also convert to objects using a context. But if you want to also use another context for values, you need a way to pass the full combined context to map elements. So, you want the following test to succeed.
252/4620 · 462
21
:141
English
For this you will have to use a different overload of `tag_invoke`. This time it has to be a function template, and it should have two parameters for contexts. The first parameter is the specific context that disambiguates that particular overload. The second parameter is the full context passed to <<ref_value_to>> or <<ref_value_from>>.
172/3390 · 339
21
:48
English
The <<ref_parse>> function offers a simple interface for converting a serialized JSON text to a <<ref_value>> in a single function call. This overload uses exceptions to indicate errors:
113/1860 · 186
21
:191
English
Simple free functions are provided for serializing a <<ref_value>> to a {std_string} containing JSON:
74/1010 · 101
22
:97
English
{icon_bad} Object types have no hash table or index to reduce the cost of
32/730 · 73
23
:54
English
are replaced with an overload accepting a <<ref_string_view>> parameter.
59/720 · 72
23
:119
English
Boost.JSON solves this problem by introducing a new smart pointer called <<ref_storage_ptr>> which builds upon {cpp}17's memory allocation interfaces, accomplishing the goals above. As a result, libraries which use this type compose more easily and enjoy faster compilation, as member functions for containers which use the type can be defined out-of-line.
169/3560 · 356
23
:98
English
lookups.
5/100 · 8
23
:61
English
Type satisfying <<ref_is_string_like>>.
57/390 · 39
24
:56
English
This design removes several redundant overloads from the interface. For example, the 11 overloads of `std::string::insert` are reduced to just 3 in <<ref_string>>, while still providing identical functionality. In addition to these changes, overloads taking a `std::initializer_list<char>` parameter have been removed. Such overloads have little use, as they serve as little more than wrappers for arrays with an inefficient syntax:
206/4320 · 432