Exit Zen
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
:20
English
If library-provided conversions are suitable for you, you have the option to use direct conversions. This also puts the requirement of being default constructible on many of your types.
48/1850 · 185
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
:17
English
Previously a number of conversion type traits, like <<ref_is_tuple_like>> or <<ref_is_sequence_like>>, were introduced. The library tries the traits one after another and uses the implementation that corresponds to the first matching trait. In some cases, though, a type would match a trait with a higher priority, but the user intends for it to belong to a lower priority category. If this happens the user can specialize the trait that's not supposed to match for that type to be an equivalent of `std::false_type`.
253/5180 · 518
3
:23
English
That being said, if your types are default-constructible and you don't need the customisability allowed by <<ref_value_to>> and <<ref_value_from>>, then you can get a significant performance boost with direct conversions.
137/2210 · 221
3
:21
English
Iterators are ordinary pointers, and may become invalidated on insertions
24/730 · 73
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
3
:24
English
After that the definitions of `tag_invoke` overloads should be provided. These overloads have to be templates, since <<ref_value>> is only forward-declared and hence is an incomplete type.
89/1880 · 188
3
:20
English
As the conversion result is set via an output parameter of type `value&`, the intended <<ref_storage_ptr>> is correctly propagated. But users still should take care to not create temporaries using the default {ref_memory_resource} by accident.
135/2430 · 243
3
:22
English
https://en.cppreference.com/w/cpp/utility/variant/monostate[__monostate__] value, equivalent to `nullptr`.
93/1060 · 106
3
:28
English
Initializer lists can be used to construct objects with initial contents. These constructors may allocate memory and throw:
41/1230 · 123
3
:18
English
type-erased {ref_memory_resource}.
29/340 · 34
3
:14
English
the simdjson parser is a read-only structure. In other words, it can't be changed, and the only way to create one is by parsing a JSON string. On the other hand, Boost.JSON allows you to modify the container holding the parsed JSON, or even build a JSON document from scratch through the container interface.
103/3080 · 308
3
:22
English
Validate
2/100 · 8
3
:23
English
include::../../README.adoc[]
28/280 · 28
3
:31
English
While the system works, it has some usability problems:
24/550 · 55
3
:19
English
:leveloffset: +1
16/160 · 16
3
:17
English
a| *Classes* + <<ref_array>> + <<ref_basic_parser>> + <<ref_key_value_pair>> + <<ref_monotonic_resource>> + <<ref_object>> + <<ref_parser>> + <<ref_parse_options>> + <<ref_serializer>> + <<ref_serialize_options>> + <<ref_set_pointer_options>> + <<ref_static_resource>> + <<ref_storage_ptr>> + <<ref_stream_parser>> + <<ref_string>> + <<ref_value>> + <<ref_value_ref>> + <<ref_value_stack>>
794/3890 · 389
3
:18
English
a {ref_polymorphic_allocator}.
31/300 · 30
3
:18
English
Description
2/110 · 11