2. Boost Json Translation (zh_Hans)
3. English
4. Zen

1 :10
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Conversion Customization Guidelines With so many options, it can be hard to choose the best way to customise conversion for your type. In this section, we will discuss those options and suggest which to choose when. 217/10000 · 217
1 :10
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Contextual Conversions Previously in this section we've been assuming that there is a particular fitting JSON representation for a type. But this is not always the case. Often one needs to represent particular value with JSON of certain format in one situation and with another format in a different situation. This can be achieved with Boost.JSON by providing an extra argument---context. 391/10000 · 391
1 :10
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Custom Conversions Boost.JSON uses two mechanisms to customize conversion between <<ref_value>> and user types. One mechanism involves specializing type traits. The other one is more powerful and requires defining overloads of `tag_invoke`. Both mechanisms will be further explained in this section. 301/10000 · 301
1 :10
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Non-Throwing Conversions For the case where throwing exceptions is undesirable, Boost.JSON also provides a non-throwing version of <<ref_value_to>>, the function template <<ref_try_value_to>>. It returns {ref_result}, a specialised variant that either holds a value or an {ref_error_code}. 292/10000 · 292
1 :13
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Value Conversion While the <<ref_value>> container makes it easy to create ad-hoc structures, often it is necessary to convert between JSON and user-defined types or types from the standard library. 200/10000 · 200
1 :10
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Direct Conversion For large inputs parsing into the library's containers followed by conversion via <<ref_value_to>> (or vice versa <<ref_value_from>> followed by serialization from a <<ref_value>>) might be prohibitively expensive. For these cases the library provides components that allow parsing directly into and serializing directly from user-provided objects. 368/10000 · 368
1 :10
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Avoiding Physical Dependency Some users, particularly library authors, may wish to provide conversions between their types and <<ref_value>>, but at the same time would prefer to avoid having their library depend on Boost.JSON. This is possible to achieve with the help of a few forward declarations. 302/10000 · 302
1 :10
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Allocation Control As <<ref_value_from>> creates a <<ref_value>> object, users may want to control the way memory is allocated for it. For this reason the function has an optional <<ref_storage_ptr>> parameter, that is used to set the {ref_memory_resource} for the result. 274/10000 · 274
1 :11
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = `storage_ptr` Variable-length containers in this library all use dynamically allocated memory to store their contents. Callers can gain control over the strategy used for allocation by specifying a <<ref_storage_ptr>> in select constructors and function parameter lists. A <<ref_storage_ptr>> has these properties: 316/10000 · 316
1 :11
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Background The first version of allocators in C++ defined the named requirement {req_Allocator}, and made each standard container a class template parameterized on the allocator type. For example, here is the declaration for {std_vector}: 240/10000 · 240
1 :12
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Allocators 12/10000 · 12
1 :12
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Uses-allocator Construction To support code bases which are already using polymorphic allocators, the containers in this library support {std_uses_allocator} construction. For <<ref_array>>, <<ref_object>>, <<ref_string>>, and <<ref_value>>: 243/10000 · 243
1 :12
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Parsing Parsing is the process where a serialized JSON text is validated and decomposed into elements. The library provides these functions and types to assist with parsing: 175/10000 · 175
1 :11
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Serializing 13/10000 · 13
1 :12
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — = Input/Output The library provides parsing and serialization algorithms to transform JSON to and from the <<ref_value>> container as needed. This is accomplished through free functions and classes, described as follows. 220/10000 · 220
2 :4
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Branch 6/10000 · 6
2 :15
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 4+|JSON 7/10000 · 7
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
2 :14
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Pretty 6/10000 · 6
:21 :21
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Name 4/10000 · 4