</code></pre></div><p>The type used to store JSON objects.</p><p><ahref=https://tools.ietf.org/html/rfc8259>RFC 8259</a> describes JSON objects as follows:</p><blockquote><p>An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array.</p></blockquote><p>To store objects in C++, a type is defined by the template parameters described below.</p><h2id=template-parameters>Template parameters<aclass=headerlinkhref=#template-parameterstitle="Permanent link">¶</a></h2><dl><dt><code>ObjectType</code></dt><dd>the container to store objects (e.g., <code>std::map</code> or <code>std::unordered_map</code>)</dd><dt><code>StringType</code></dt><dd>the type of the keys or names (e.g., <code>std::string</code>). The comparison function <code>std::less<StringType></code> is used to order elements inside the container.</dd><dt><code>AllocatorType</code></dt><dd>the allocator to use for objects (e.g., <code>std::allocator</code>)</dd></dl><h2id=notes>Notes<aclass=headerlinkhref=#notestitle="Permanent link">¶</a></h2><h4id=default-type>Default type<aclass=headerlinkhref=#default-typetitle="Permanent link">¶</a></h4><p>With the default values for <code>ObjectType</code> (<code>std::map</code>), <code>StringType</code> (<code>std::string</code>), and <code>AllocatorType</code> (<code>std::allocator</code>), the default value for <code>object_t</code> is:</p><divclass=highlight><pre><span></span><code><spanclass=c1>// until C++14</span>
</code></pre></div><p>See <ahref=../default_object_comparator_t/><code>default_object_comparator_t</code></a> for more information.</p><h4id=behavior>Behavior<aclass=headerlinkhref=#behaviortitle="Permanent link">¶</a></h4><p>The choice of <code>object_t</code> influences the behavior of the JSON class. With the default type, objects have the following behavior:</p><ul><li>When all names are unique, objects will be interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings.</li><li>When the names within an object are not unique, it is unspecified which one of the values for a given key will be chosen. For instance, <codeclass=highlight><spanclass=p>{</span><spanclass=nt>"key"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>2</span><spanclass=p>,</span><spanclass=w></span><spanclass=nt>"key"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>1</span><spanclass=p>}</span></code> could be equal to either <codeclass=highlight><spanclass=p>{</span><spanclass=nt>"key"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>1</span><spanclass=p>}</span></code> or <codeclass=highlight><spanclass=p>{</span><spanclass=nt>"key"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>2</span><spanclass=p>}</span></code>.</li><li>Internally, name/value pairs are stored in lexicographical order of the names. Objects will also be serialized (see <ahref=../dump/><code>dump</code></a>) in this order. For instance, <codeclass=highlight><spanclass=p>{</span><spanclass=nt>"b"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>1</span><spanclass=p>,</span><spanclass=w></span><spanclass=nt>"a"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>2</span><spanclass=p>}</span></code> and <codeclass=highlight><spanclass=p>{</span><spanclass=nt>"a"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>2</span><spanclass=p>,</span><spanclass=w></span><spanclass=nt>"b"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>1</span><spanclass=p>}</span></code> will be stored and serialized as <codeclass=highlight><spanclass=p>{</span><spanclass=nt>"a"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>2</span><spanclass=p>,</span><spanclass=w></span><spanclass=nt>"b"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>1</span><spanclass=p>}</span></code>.</li><li>When comparing objects, the order of the name/value pairs is irrelevant. This makes objects interoperable in the sense that they will not be affected by these differences. For instance, <codeclass=highlight><spanclass=p>{</span><spanclass=nt>"b"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>1</span><spanclass=p>,</span><spanclass=w></span><spanclass=nt>"a"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>2</span><spanclass=p>}</span></code> and <codeclass=highlight><spanclass=p>{</span><spanclass=nt>"a"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>2</span><spanclass=p>,</span><spanclass=w></span><spanclass=nt>"b"</span><spanclass=p>:</span><spanclass=w></span><spanclass=mi>1</span><spanclass=p>}</span></code> will be treated as equal.</li></ul><h4id=limits>Limits<aclass=headerlinkhref=#limitstitle="Permanent link">¶</a></h4><p><ahref=https://tools.ietf.org/html/rfc8259>RFC 8259</a> specifies:</p><blockquote><p>An implementation may set limits on the maximum depth of nesting.</p></blockquote><p>In this class, the object's limit of nesting is not explicitly constrained. However, a maximum depth of nesting may be introduced by the compiler or runtime environment. A theoretical limit can be queried by calling the <ahref=../max_size/><code>max_size</code></a> function of a JSON object.</p><h4id=storage>Storage<aclass=hea
