2. Boost Json Translation (zh_Hans)
3. Doc / Pages / Quick Look (adoc)
4. English
5. Zen

2 :23
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In order to link your program you will need to link with a built library. Alternatively you can use the header-only configuration simply by including this header file in any __one__ of your new or existing source files: 219/10000 · 219
3 :45
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Values 6/10000 · 6
4 :46
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Say you want to recreate this JSON object in a container: 57/10000 · 57
5 :66
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 280/10000 · 280
6 :76
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 324/10000 · 324
7 :87
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 343/10000 · 343
8 :99
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Allocators 10/10000 · 10
9 :100
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 419/10000 · 419
10 :112
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The containers in this library enforce the invariant that every element of the container will use the same memory resource: 123/10000 · 123
11 :120
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a library type is used as the element type of a PMR container; that is, a container which uses a {ref_polymorphic_allocator}, the memory resource will automatically propagate to the type and all of its children: 216/10000 · 216
12 :129
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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>>: 387/10000 · 387
13 :141
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A counted memory resource will not be destroyed until every container with shared ownership of the resource is destroyed. 121/10000 · 121
14 :145
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Parsing 7/10000 · 7
15 :146
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 154/10000 · 154
16 :154
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Error codes are also possible: 30/10000 · 30
17 :161
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — By default, the parser is strict and only accepts JSON compliant with the standard. However this behavior can be relaxed by filling out an options structure enabling one or more extensions. Here we use a static buffer and enable two non-standard extensions: 257/10000 · 257
18 :171
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The parser in this library implements a https://en.wikipedia.org/wiki/Online_algorithm[__streaming algorithm__]; it can process JSON piece-by-piece, without the requirement that the entire input is available from the start. The parser uses a temporary memory allocation to do its work. If you plan on parsing multiple JSONs, for example in a network server, keeping the same parser instance will allow re-use of this temporary storage, improving performance. 458/10000 · 458
19 :184
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — With strategic use of the right memory resources, parser instance, and calculated upper limits on buffer sizes, it is possible to parse and examine JSON without __any__ dynamic memory allocations. This is explored in more detail in a later section. 248/10000 · 248
20 :190
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Serializing 11/10000 · 11
21 :191
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Simple free functions are provided for serializing a <<ref_value>> to a {std_string} containing JSON: 101/10000 · 101