Exit Zen
24
:36
English
https://codecov.io/gh/boostorg/json/branch/master[image:https://codecov.io/gh/boostorg/json/branch/master/graph/badge.svg[codecov]]
131/1310 · 131
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
24
:57
English
{ref_memory_resource}
21/210 · 21
24
:72
English
The <<ref_value>> returned in the preceding examples use the <<default_memory_resource,default memory resource>>. The following code uses a <<ref_monotonic_resource>>, which results in faster parsing. `jv` is marked `const` to prevent subsequent modification, because containers using a monotonic resource waste memory when mutated.
277/3320 · 332
24
:100
English
{icon_bad} Allocators have reference semantics. Problems with lifetime are
32/740 · 74
25
:36
English
https://codecov.io/gh/boostorg/json/branch/develop[image:https://codecov.io/gh/boostorg/json/branch/develop/graph/badge.svg[codecov]]
133/1330 · 133
25
:68
English
With the removal of overloads that specify parameters for a substring, a member function `subview` that returns a <<ref_string_view>> is provided to facilitate cheap substring operations:
105/1870 · 187
25
:218
English
We can define a conversion from the user-defined type to a <<ref_value>> by defining an overload of `tag_invoke` in the same namespace. This maps `customer` to a JSON object:
107/1740 · 174
25
:101
English
easily encountered.
7/190 · 19
25
:61
English
The result is a <<ref_string>>.
38/310 · 31
26
:41
English
Boost.JSON
10/100 · 10
26
:77
English
A <<ref_string>> may be constructed using the <<default_memory_resource,default memory resource>> without incurring any memory allocations. Alternatively, a <<ref_storage_ptr>> can be provided explicitly:
218/2040 · 204
26
:84
English
Unless otherwise specified, the parser in this library is strict. It recognizes only valid, standard JSON. The parser can be configured to allow certain non-standard extensions by filling in a <<ref_parse_options>> structure and passing it by value. By default all extensions are disabled:
131/2890 · 289
26
:227
English
This allows us to use the library function <<ref_value_from>> to produce a <<ref_value>> from our type:
98/1030 · 103
26
:78
English
125KB
5/100 · 5
26
:61
English
The result is constructed from a <<ref_string_view>>.
51/530 · 53
27
:94
English
When building with {cpp}20 or later, the use of https://en.cppreference.com/w/cpp/language/aggregate_initialization#Designated_initializers[designated initializers] with <<ref_parse_options>> is possible:
176/2040 · 204
27
:61
English
Type satisfying <<ref_is_variant_like>>.
59/400 · 40
28
:88
English
When a <<ref_string>> is formatted to a {std_ostream}, the result is a valid JSON. That is, the result will be double quoted and the contents properly escaped per the JSON specification.
101/1860 · 186
28
:243
English
To go from JSON to a user-defined type we use <<ref_value_to>>, which uses another overload of `tag_invoke`. This converts a JSON value to a `customer`. It throws an exception if the contents of the value do not match what is expected:
129/2350 · 235