Exit Zen
3
:18
English
The interface and functionality of <<ref_string>> is the same as {std_string} except that:
65/900 · 90
3
:36
English
In cases where you know that a <<ref_value>> contains a number but don't know its <<ref_kind>>, `value::to_number` can be used to convert the <<ref_value>> to an arithmetic type:
142/1780 · 178
3
:25
English
These `tag_invoke` overloads take an extra `as_string` parameter, which disambiguates this specific representation of `ip_address` from all other potential representations. In order to take advantage of them one needs to pass an `as_string` object to <<ref_value_from>> or <<ref_value_to>> as the last argument:
196/3110 · 311
3
:21
English
The library provides non-throwing conversions for all the categories of types it supports with <<ref_value_to>>. If a user wants to use it with custom types, an overload of `tag_invoke` of this form needs to be provided:
107/2200 · 220
4
:36
English
The library also allows changing and adding deeply nested elements. The function <<ref_value_set_at_pointer>> traverses the value similarly to <<ref_value_at_pointer>>, but additionally, it can create missing elements in certain cases:
166/2350 · 235
4
:45
English
If the <<ref_value>> does not contain a number, or if the conversion is to an integer type `T` and the number cannot be represented exactly by `T`, the conversion will fail. Otherwise, the result is the number converted to `T` as-if by `static_cast`:
110/2500 · 250
4
:34
English
When a two element initializer list is nested within an enclosing initializer list, it is unclear whether it represents an <<ref_array>> or an <<ref_object>>:
111/1580 · 158
5
:46
English
The specific behavior is controlled by an optional parameter of type <<ref_set_pointer_options>>. For example, here's the same example with a different option:
97/1590 · 159
5
:30
English
For the class `ip_address` from the section <<custom_conversions>> this overload may look like this:
84/1000 · 100
5
:43
English
Similar to its standard library counterpart, elements may be accessed directly by their 0-based index with bounds checking using <<ref_array_at>>, or without bounds checking using <<ref_array_operator_lb_rb>>:
166/2090 · 209
5
:66
English
In this library the types <<ref_array>>, <<ref_object>>, and <<ref_string>> hold JSON arrays, objects, and strings respectively while the type <<ref_value>> is a special variant which can hold any JSON element. Here we construct an empty object and then insert the elements above:
223/2800 · 280
6
:76
English
While keys are strings, the mapped type of objects and the element type of arrays is the aforementioned type <<ref_value>> which can hold any JSON element, as seen in the previous assignments. Instead of building the JSON document using a series of function calls, we can build it in one statement using an initializer list:
135/3240 · 324
7
:87
English
When a <<ref_value>>, <<ref_array>>, or <<ref_object>> is assigned or constructed from an initializer list, the creation of the new value happens only once. This makes initializer lists equally efficient as using the other ways to create a value. The types in this library are first-class, supporting copy and move construction and assignment:
181/3430 · 343
7
:59
English
Initializer lists can be used to unambiguously construct or assign an <<ref_object>> or <<ref_array>>:
86/1020 · 102
8
:29
English
An empty object may be constructed without incurring any memory allocations using the <<default_memory_resource,default memory resource>>. A <<ref_storage_ptr>> can also be explicitly specified:
175/1940 · 194
8
:67
English
Similarly, an initializer list for an <<ref_object>> is always interpreted as an <<ref_object>>. In such cases, the initializer list must be a list of key-value pairs. For example, the following code will not compile because `1` is not convertible to a string:
133/2600 · 260
9
:100
English
To permit custom memory allocation strategies, these containers all allow construction with a <<ref_storage_ptr>> which is a smart pointer to a {ref_memory_resource}. The constructor signatures have the same ordering as their `std` equivalents which use {req_Allocator} parameters. Once a container is constructed its memory resource can never change. Here we create an array without performing any dynamic allocations:
192/4190 · 419
11
:54
English
Similar to the `std` counterpart, elements may be accessed directly by their key with bounds checking using <<ref_object_at>>, or without bounds checking using <<ref_object_operator_lb_rb>> which creates a null element if the key does not already exist:
165/2530 · 253
12
:38
English
A <<ref_value>> constructed from `nullptr` or default constructed represents a null JSON element:
64/970 · 97
12
:129
English
Up until now we have shown how values may be constructed from a memory resource pointer, where ownership is not transferred. In this case the caller is responsible for ensuring that the lifetime of the resource is extended for the life of the container. Sometimes you want the container to acquire shared ownership of the resource. This is accomplished with <<ref_make_shared_resource>>:
144/3870 · 387