The translation has come to an end.
The translation has come to an end.
Zen

Source string Source string

104/10000 · 104

The string is read-only.

Key English Actions
This library adopts a "kitchen sink" approach. It contains a wealth of features, even those with niche uses. Its weakness is that the many template parameters, while allowing for configurability, inhibit the best possible optimizations. The consequence is that the library performs poorly. The ability to configure every aspect of the value type has the paradoxical effect of making it less suitable as a vocabulary type.
{icon_bad} `basic_json` is a class template. Libraries must agree on the
choices of template parameters to be interoperable.
{icon_bad} Too much customization. We struggle to see a use case for making
`BooleanType` anything other than `bool`.
{icon_bad} Poor separation of concerns. The `basic_json` container
declaration needlessly conflates parsing and serialization APIs.
{icon_bad} Limited allocator support. Only stateless allocators are allowed,
which rules out the most important type of allocator, a local arena-based implementation.
:70
{icon_bad} No incremental parsing, no incremental serialization.
{icon_bad} Slow parsing and serialization performance.
{icon_good} Full-featured, including JSON Pointer, CBOR, and others.
Comparison to RapidJSON
Value Type: https://github.com/Tencent/rapidjson/blob/bb5f966b9939d6cdfbac3462a0410e185099b3af/include/rapidjson/document.h#L608[`rapidjson::GenericValue`]
{icon_bad} The value type is not regular. Assignment is destructive,
performing `a = b` is equivalent to `a = std::move(b)`. No copy construction or copy assignment allowed.
{icon_bad} Object types have no hash table or index to reduce the cost of
lookups.
{icon_bad} Allocators have reference semantics. Problems with lifetime are
easily encountered.
{icon_bad} The interface of the array and object types are considerably
different from their standard library equivalents, and not idiomatic.
:106
{icon_bad} No incremental parsing, no incremental serialization.
{icon_good} Parsing and serialization performance is better than most other
libraries.
Comparison to SIMD JSON
This is quite an interesting data structure, which is optimized to work well with the SIMD parser. It makes very good design choices for the intended use-case. However it is not well suited as a vocabulary type due to the necessary limitations.
{icon_bad} Sequential access only, via `ParsedJson::BasicIterator`
{icon_bad} Read-only, can only be populated by the provided SIMD JSON parser.
{icon_good} The fastest available JSON parser.
Key English Actions
{icon_bad} Read-only, can only be populated by the provided SIMD JSON parser.
{icon_bad} `basic_json` is a class template. Libraries must agree on the
choices of template parameters to be interoperable.
{icon_bad} Too much customization. We struggle to see a use case for making
`BooleanType` anything other than `bool`.
{icon_bad} Poor separation of concerns. The `basic_json` container
declaration needlessly conflates parsing and serialization APIs.
{icon_bad} Limited allocator support. Only stateless allocators are allowed,
which rules out the most important type of allocator, a local arena-based implementation.
{icon_bad} Sequential access only, via `ParsedJson::BasicIterator`
= Comparison to Other Libraries
{icon_bad} Slow parsing and serialization performance.
{icon_good} Full-featured, including JSON Pointer, CBOR, and others.
Comparison to RapidJSON
Value Type: https://github.com/Tencent/rapidjson/blob/bb5f966b9939d6cdfbac3462a0410e185099b3af/include/rapidjson/document.h#L608[`rapidjson::GenericValue`]
{icon_bad} The value type is not regular. Assignment is destructive,
performing `a = b` is equivalent to `a = std::move(b)`. No copy construction or copy assignment allowed.
{icon_bad} Object types have no hash table or index to reduce the cost of
lookups.
{icon_bad} Allocators have reference semantics. Problems with lifetime are
easily encountered.
{icon_bad} The interface of the array and object types are considerably
different from their standard library equivalents, and not idiomatic.
{icon_good} Parsing and serialization performance is better than most other
libraries.
Comparison to SIMD JSON
This is quite an interesting data structure, which is optimized to work well with the SIMD parser. It makes very good design choices for the intended use-case. However it is not well suited as a vocabulary type due to the necessary limitations.
:106
{icon_bad} No incremental parsing, no incremental serialization.
:70
{icon_bad} No incremental parsing, no incremental serialization.

Loading…

User avatar admin

String added in the repository
performing `a = b` is equivalent to `a = std::move(b)`. No copy construction or copy assignment allowed.
performing `a = b` is equivalent to `a = std::move(b)`. No copy construction or copy assignment allowed.
06/05/2026
Browse all string changes

Glossary

English English
No related strings found in the glossary.

String information

Flags
read-only, safe-html, strict-same
Unit identifier
35406
Source string location
:94
String age
06/05/2026
Last updated
06/05/2026
Source string age
06/05/2026
Translation file AsciiDoc file
doc/pages/comparison.adoc, string 21