Exit Zen
15
:146
English
JSON can be parsed into the value container in one step using a free function. In the following snippet, a parse error is indicated by a thrown exception:
45/1540 · 154
15
:49
English
https://rapidjson.org/classrapidjson_1_1_crt_allocator.html[`CrtAllocator`], which uses the standard C++ allocator, and is designed for general use including mutation of the document after it is parsed. The https://rapidjson.org/classrapidjson_1_1_generic_document.html[`Document`] object holding temporary memory is not reused between trials, otherwise memory consumption grows without bounds and invalidates the benchmark.
245/4240 · 424
:70
:70
English
{icon_bad} No incremental parsing, no incremental serialization.
29/640 · 64
15
:42
English
The <<ref_serialize>> function converts a <<ref_value>> into a {std_string}:
95/760 · 76
15
:58
English
`std::int64_t`, if `T` is a signed integer'; or
32/470 · 47
16
:23
English
http://www.boost.org/development/tests/develop/developer/json.html[image:https://img.shields.io/badge/matrix-develop-brightgreen.svg[Matrix]]
139/1410 · 141
16
:41
English
These containers are explored in-depth in the sections that follow.
67/670 · 67
16
:46
English
substring, or
6/130 · 13
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
:74
English
``` T tag_invoke( const value_to_tag< T >&, const value& ); ```
77/630 · 63
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
:41
English
Returns a pointer to a memory resource instance which always throws an
22/700 · 70
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
:38
:38
English
A stateful DOM parser object which may be used to efficiently parse a series
25/760 · 76
16
:154
English
Error codes are also possible:
7/300 · 30
16
:56
English
*nlohmann*
10/100 · 10
16
:72
English
{icon_bad} Slow parsing and serialization performance.
22/540 · 54
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
16
:59
English
`std::uint64_t`, if `T` is an unsigned integer; or
33/500 · 50