Exit Zen
1
:10
English
= 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.
144/3010 · 301
1
:10
English
= 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.
219/3680 · 368
1
:12
English
= `object` A <<ref_value>> stores an instance of <<ref_object>> as the underlying representation for a JSON object. Instances of the <<ref_object>> type are associative containers holding key and value pairs, where the key is a <<ref_string_view>> and the mapped type is a <<ref_value>>. These containers are modelled after standard maps with these properties:
266/3600 · 360
1
:10
English
= 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}.
199/2920 · 292
1
:10
English
= 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.
115/3020 · 302
1
:10
English
= 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.
195/2740 · 274
1
:12
English
= `value` JSON documents are represented in memory as instances of <<ref_value>>: a {req_Regular} type which satisfies {req_DefaultConstructible}, {req_CopyConstructible}, {req_CopyAssignable}, {req_MoveConstructible}, {req_MoveAssignable}, and many of the requirements of allocator-aware containers. It is implemented as a https://en.wikipedia.org/wiki/Tagged_union[__variant__] internally, and can dynamically store any of the six defined JSON value types:
306/4580 · 458
1
:12
English
= `array` A <<ref_value>> stores an instance of <<ref_array>> as the underlying representation for a JSON array. Instances of the __array__ type function identically to a {std_vector} of <<ref_value>>. Additionally, all values inserted into the container will use the same <<ref_storage_ptr>> as the container itself.
242/3170 · 317
1
:11
English
= `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:
177/3160 · 316
1
:11
English
= Frequently Asked Questions
6/280 · 28
1
:12
English
= Examples
4/100 · 10
1
:11
English
= Boost.JSON (C) 2019--2020 Vinnie Falco; (C) 2020 Krystian Stasiowski; (C) 2022 Dmitry Arkhipov :idprefix: :sectanchors: :toclevels: 2 :toc: left :pagelevels: 2 :source-highlighter: rouge :source-language: c++
210/2100 · 210
1
:11
English
= 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}:
93/2400 · 240
1
:12
English
= Allocators
5/120 · 12
1
:11
English
= Reference
4/110 · 11
1
:12
English
= 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>>:
198/2430 · 243
1
:12
English
= 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:
48/1750 · 175
1
:12
English
= Quick Look Here we highlight important features through example code to help convey the style of the interface. We begin by including the library header file which brings all the symbols into scope. Alternatively, individual headers may be included to obtain the declarations for specific types:
84/2970 · 297
1
:12
English
= Benchmarks This section compares the performance of Boost.JSON with two widely used libraries with similar functionality: RapidJSON which is known for its performance, and JSON for Modern C++ which is known for feature-richness. The bench program measures the throughput of parsing and serialization for the a set of JSON representing typical workloads. These implementations are evaluated:
155/3920 · 392
1
:12
English
= Comparison to Other Libraries
9/310 · 31