Exit Zen
41
:151
English
To use the <<ref_parser>>, declare an instance. Then call <<ref_parser_write>> once with the buffer containing representing the input JSON. Finally, call <<ref_parser_release>> to take ownership of the resulting <<ref_value>> upon success. This example persists the parser instance in a class member to reuse across calls:
250/3220 · 322
41
:87
English
Type satisfying <<ref_is_tuple_like>>.
55/380 · 38
42
:162
English
Sometimes a protocol may have a JSON text followed by data that is in a different format or specification. The JSON portion can still be parsed by using the function <<ref_parser_write_some>>. Upon success, the return value will indicate the number of characters consumed from the input, which will exclude the non-JSON characters:
151/3310 · 331
45
:116
English
The <<ref_monotonic_resource>> optimizes this memory allocation pattern by allocating increasingly large blocks of global memory internally and parceling those blocks out in smaller pieces to fulfill allocation requests. It has a trivial deallocate function. The monotonic resource does not actually deallocate memory until the resource is destroyed. Thus, it is ideally suited for the use-case where JSON is parsed, and the resulting value is then inspected but not modified.
187/4760 · 476
45
:182
English
The <<ref_stream_parser>> implements a https://en.wikipedia.org/wiki/Online_algorithm[__streaming algorithm__]; it allows incremental processing of large JSON inputs using one or more contiguous character buffers. The entire input JSON does not need to be loaded into memory at once. A network server can use the streaming interface to process incoming JSON in fixed-size amounts, providing these benefits:
198/4060 · 406
45
:87
English
The result is an <<ref_object>> with described members' names as keys.
52/700 · 70
46
:124
English
The resource to use when constructing values may be specified in calls to <<ref_parse>> as shown here:
58/1020 · 102
46
:87
English
The result is default-constructed and described members are assigned
25/680 · 68
50
:151
English
A <<ref_static_resource>> constructs from a caller-provided buffer, and satisfies all memory allocation requests from the buffer. Once the buffer is exhausted, subsequent calls to allocate throw the exception `std::bad_alloc`. The resource offers a simple invariant: dynamic heap allocations are never performed.
147/3120 · 312
50
:194
English
To use the <<ref_stream_parser>>, declare an instance. Then call <<ref_stream_parser_write>> zero or more times with successive buffers representing the input JSON. When there are no more buffers, call <<ref_stream_parser_finish>>. The function <<ref_stream_parser_done>> returns `true` after a successful call to `write` or `finish` if parsing is complete.
324/3570 · 357
50
:111
English
a <<ref_string>>, containing its name. Otherwise it's equal to the input value converted to its underlying type. |The result is the described enumerator, corresponding to the input <<ref_string>>.
70/1960 · 196
51
:200
English
In the following example a JSON text is parsed from standard input a line at a time. Error codes are used instead. The function <<ref_stream_parser_finish>> is used to indicate the end of the input:
107/1980 · 198
51
:116
English
Type satisfying <<ref_is_path_like>>.
53/370 · 37
53
:165
English
The function <<ref_get_null_resource>> returns a global instance of the null resource. This resource offers a simple invariant: all calls to allocate will throw the exception `std::bad_alloc`. An instance of the null resource can be used to make parsing guarantee that allocations from the heap are never made. This is explored in more detail in a later section.
162/3620 · 362
53
:205
English
`std::getline` use (see the warning in <<non_standard_json>> section).
80/700 · 70
55
:172
English
The containers <<ref_array>>, <<ref_object>>, and <<ref_value>> all propagate the memory resource they were constructed with to child elements:
127/1430 · 143
56
:221
English
After default construction, or after <<ref_stream_parser_reset>> is called with no arguments, the <<ref_value>> produced after a successful parse operation uses the default memory resource. To use a different memory resource, call `reset` with the resource to use. Here we use a <<ref_monotonic_resource>>, which is optimized for parsing but not subsequent modification:
249/3700 · 370
56
:130
English
Here, the map is converted into an <<ref_object>>, since it matches <<ref_is_map_like>>. Each of its keys is converted into a <<ref_string>>, as `std::string` matches <<ref_is_string_like>>, and each of its values is converted into an <<ref_array>>, as `std::pair` matches <<ref_is_tuple_like>>. Finally, elements of pairs are converted into a `std::int64_t` number and a `bool`.
408/3790 · 379
58
:185
English
It is important to note that <<ref_storage_ptr>> supports both shared-ownership and reference lifetime models. Construction from a memory resource pointer does not transfer ownership:
88/1830 · 183
60
:200
English
Shared ownership is achieved using the function <<ref_make_shared_resource>>, which creates a new, reference-counted memory resource using a dynamic memory allocation and returns it as a <<ref_storage_ptr>>:
160/2070 · 207