Exit Zen
16
:23
English
http://www.boost.org/development/tests/develop/developer/json.html[image:https://img.shields.io/badge/matrix-develop-brightgreen.svg[Matrix]]
139/1410 · 141
16
:41
English
These containers are explored in-depth in the sections that follow.
67/670 · 67
16
:46
English
substring, or
6/130 · 13
16
:100
English
Often it is needed to use several conversion contexts together. For example, consider a log of remote users identified by IP addresses accessing a system. We can represent it as `std::vector<std::pair<std::chrono::system_clock::time_point, ip_address>>`. We want to serialize both ``ip_address``es and ``time_point``s as strings, but for this we need both `as_string` and `as_iso_8601` contexts. To combine several contexts just use {std_tuple}. Conversion functions will select the first element of the tuple for which a `tag_invoke` overload exists and will call that overload. As usual, `tag_invoke` overloads that don't use contexts and library-provided generic conversions are also supported. Thus, here's our example:
396/7230 · 723
16
:74
English
``` T tag_invoke( const value_to_tag< T >&, const value& ); ```
77/630 · 63
16
:93
English
When an <<ref_object>> is formatted to a {std_ostream}, the result is a valid JSON. That is, the object will be output with curly braces and a comma separated list of key/value pairs, as per the JSON specification.
109/2140 · 214
16
:80
English
The following table shows all of the ways to determine and access the contents of a <<ref_value>>:
53/980 · 98
16
:41
English
Returns a pointer to a memory resource instance which always throws an
22/700 · 70
16
:102
English
Workarounds for this problem are worse than the problem itself. The library could return a pair with the vector and `std::unique_ptr<std::pmr::memory_resource>` which the caller must manage. Or the library could change its function signatures to accept a {ref_memory_resource}``*`` provided by the caller, where the library also makes public the desired memory resources (`my_resource` above).
212/3930 · 393
:38
:38
English
A stateful DOM parser object which may be used to efficiently parse a series
25/760 · 76
16
:154
English
Error codes are also possible:
7/300 · 30
16
:56
English
*nlohmann*
10/100 · 10
16
:72
English
{icon_bad} Slow parsing and serialization performance.
22/540 · 54
16
:49
English
In situations where serializing a <<ref_value>> in its entirety is inefficient or even impossible, <<ref_serializer>> can be used to serialize a <<ref_value>> incrementally. This may be done for a variety of reasons, such as to avoid buffering the entire output, or to ensure that a fixed amount of work is performed in each cycle. Instances of <<ref_serializer>> maintain an output state using internal dynamically allocated structures, with an interface to retrieve successive buffers of the serialized output into a caller provided buffer. Here is an example, demonstrating how <<ref_operator_lt_lt>> may be implemented using a <<ref_serializer>>:
349/6500 · 650
16
:59
English
`std::uint64_t`, if `T` is an unsigned integer; or
33/500 · 50
17
:23
English
Fuzzing
4/100 · 7
17
:55
English
:leveloffset: +1 include::value.adoc[] include::string.adoc[] include::array.adoc[] include::object.adoc[] include::numbers.adoc[] include::init_lists.adoc[] include::nested_access.adoc[] :leveloffset: -1
204/2040 · 204
17
:47
English
a parameter of a type convertible to <<ref_string_view>>, or
58/600 · 60
17
:117
English
In this snippet `time_point` is converted using `tag_invoke` overload that takes `as_iso_8601`, `ip_address` is converted using `tag_invoke` overload that takes `as_string`, and {std_vector} is converted using a generic conversion provided by the library.
133/2550 · 255
17
:78
English
If we implemented conversion for `user_ns::ip_address` manually with this approach, it would look like this:
51/1080 · 108