Exit Zen
16
:41
English
These containers are explored in-depth in the sections that follow.
67/670 · 67
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
:56
English
*nlohmann*
10/100 · 10
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
:55
English
:leveloffset: +1 include::value.adoc[] include::string.adoc[] include::array.adoc[] include::object.adoc[] include::numbers.adoc[] include::init_lists.adoc[] include::nested_access.adoc[] :leveloffset: -1
204/2040 · 204
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
:23
English
https://ci.appveyor.com/[Appveyor]
34/340 · 34
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
20
:66
English
The input files are all loaded first. Then each configuration is run for a sufficient number of trials to last at least 5 seconds. The elapsed time, number of invocations (of parse or serialize), and bytes transferred are emitted as a sample along with a calculation of throughput expressed in megabytes per second. Several samples (currently five) are generated for each configuration. All but the median two samples are discarded, with the remaining samples averaged to produce a single number which is reported as the benchmark result.
176/5380 · 538
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
:78
:78
English
Name
5/100 · 4