= `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:

It exposes both a sequence API and a tuple API. But converting from <<ref_value>> to `user_ns::ip_address` would not be able to use implementation for sequences, since those are constructed empty and then populated one element at a time, while `ip_address` has a fixed size of 4. The tuple conversion would fit, though. The only problem is that <<ref_is_tuple_like>> has a lower priority than <<ref_is_sequence_like>>. In order to circumvent this, the user only needs to specialize <<ref_is_sequence_like>> to not match `ip_address`.

The opposite is also true: if there's a `tag_invoke` overload intended for <<ref_try_value_to>>, but not for <<ref_value_to>>, then calling <<ref_value_to>> will invoke the non-throwing overload, then construct a {ref_system_error} from the {ref_error_code} and throw it. Due to these fallbacks, it is recommended that users provide the overload from this section, rather then the other one, if they ever intend to use <<ref_try_value_to>>.

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>>: