deploy: 4e294f4b18
This commit is contained in:
nlohmann committed
1 parent
dcc7a74a18
commit
98c9bea1d1
105 files changed
+537
-508
No files matched your search
@@ -68,7 +68,7 @@ basic_json .. value_t</code></pre> <h2 id=template-arguments>Template arguments<
|
||||
<span class=k>using</span><span class=w> </span><span class=n>number_float_t</span><span class=w> </span><span class=o>=</span><span class=w> </span><span class=n>NumberFloatType</span><span class=p>;</span>
|
||||
|
||||
<span class=k>using</span><span class=w> </span><span class=n>binary_t</span><span class=w> </span><span class=o>=</span><span class=w> </span><span class=n>nlohmann</span><span class=o>::</span><span class=n>byte_container_with_subtype</span><span class=o><</span><span class=n>BinaryType</span><span class=o>></span><span class=p>;</span>
|
||||
</code></pre></div> <p>Not every type can be passed for these template arguments: the library uses the resulting types in ways that imply a number of requirements, for instance that <code>StringType</code> is <code>char</code>-based or that <code>ArrayType</code> is vector-like. These requirements are collected in <a href=template_parameters/ >Template Parameter Requirements</a>.</p> <h2 id=objects>Objects<a class=headerlink href=#objects title="Permanent link">¶</a></h2> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> describes <abbr title="JavaScript Object Notation">JSON</abbr> 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> <h3 id=default-type>Default type<a class=headerlink href=#default-type title="Permanent link">¶</a></h3> <p>With the default values for <em>ObjectType</em> (<code>std::map</code>), <em>StringType</em> (<code>std::string</code>), and <em>AllocatorType</em> (<code>std::allocator</code>), the default value for <code>object_t</code> is:</p> <div class=highlight><pre><span></span><code><span class=n>std</span><span class=o>::</span><span class=n>map</span><span class=o><</span>
|
||||
</code></pre></div> <p>Not every type can be passed for these template arguments: the library uses the resulting types in ways that imply a number of requirements, for instance that <code>StringType</code> is <code>char</code>-based or that <code>ArrayType</code> is vector-like. These requirements are collected in <a href=template_parameters/ >Template Parameter Requirements</a>.</p> <h2 id=objects>Objects<a class=headerlink href=#objects title="Permanent link">¶</a></h2> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> describes <abbr title="JavaScript Object Notation">JSON</abbr> 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> <h3 id=default-type>Default type<a class=headerlink href=#default-type title="Permanent link">¶</a></h3> <p>With the default values for <em>ObjectType</em> (<code>std::map</code>), <em>StringType</em> (<code>std::string</code>), and <em>AllocatorType</em> (<code>std::allocator</code>), the default type for <code>object_t</code> is:</p> <div class=highlight><pre><span></span><code><span class=n>std</span><span class=o>::</span><span class=n>map</span><span class=o><</span>
|
||||
<span class=w> </span><span class=n>std</span><span class=o>::</span><span class=n>string</span><span class=p>,</span><span class=w> </span><span class=c1>// key_type</span>
|
||||
<span class=w> </span><span class=n>basic_json</span><span class=p>,</span><span class=w> </span><span class=c1>// value_type</span>
|
||||
<span class=w> </span><span class=n>std</span><span class=o>::</span><span class=n>less</span><span class=o><></span><span class=p>,</span><span class=w> </span><span class=c1>// key_compare</span>
|
||||
@@ -77,8 +77,8 @@ basic_json .. value_t</code></pre> <h2 id=template-arguments>Template arguments<
|
||||
</code></pre></div> <h3 id=behavior>Behavior<a class=headerlink href=#behavior title="Permanent link">¶</a></h3> <p>The choice of <code>object_t</code> influences the behavior of the <abbr title="JavaScript Object Notation">JSON</abbr> 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, <code class=highlight><span class=p>{</span><span class=nt>"key"</span><span class=p>:</span><span class=w> </span><span class=mi>2</span><span class=p>,</span><span class=w> </span><span class=nt>"key"</span><span class=p>:</span><span class=w> </span><span class=mi>1</span><span class=p>}</span></code> could be equal to either <code class=highlight><span class=p>{</span><span class=nt>"key"</span><span class=p>:</span><span class=w> </span><span class=mi>1</span><span class=p>}</span></code> or <code class=highlight><span class=p>{</span><span class=nt>"key"</span><span class=p>:</span><span class=w> </span><span class=mi>2</span><span class=p>}</span></code>. To reject duplicate keys instead of silently resolving them one way or another, see <a href=../parsing/parser_callbacks/#recipe-rejecting-duplicate-object-keys>this parsing recipe</a>.</li> <li>Internally, name/value pairs are stored in lexicographical order of the names. Objects will also be serialized (see <code>dump</code>) in this order. For instance, both <code class=highlight><span class=p>{</span><span class=nt>"b"</span><span class=p>:</span><span class=w> </span><span class=mi>1</span><span class=p>,</span><span class=w> </span><span class=nt>"a"</span><span class=p>:</span><span class=w> </span><span class=mi>2</span><span class=p>}</span></code> and <code class=highlight><span class=p>{</span><span class=nt>"a"</span><span class=p>:</span><span class=w> </span><span class=mi>2</span><span class=p>,</span><span class=w> </span><span class=nt>"b"</span><span class=p>:</span><span class=w> </span><span class=mi>1</span><span class=p>}</span></code> will be stored and serialized as <code class=highlight><span class=p>{</span><span class=nt>"a"</span><span class=p>:</span><span class=w> </span><span class=mi>2</span><span class=p>,</span><span class=w> </span><span class=nt>"b"</span><span class=p>:</span><span class=w> </span><span class=mi>1</span><span class=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, <code class=highlight><span class=p>{</span><span class=nt>"b"</span><span class=p>:</span><span class=w> </span><span class=mi>1</span><span class=p>,</span><span class=w> </span><span class=nt>"a"</span><span class=p>:</span><span class=w> </span><span class=mi>2</span><span class=p>}</span></code> and <code class=highlight><span class=p>{</span><span class=nt>"a"</span><span class=p>:</span><span class=w> </span><span class=mi>2</span><span class=p>,</span><span class=w> </span><span class=nt>"b"</span><span class=p>:</span><span class=w> </span><span class=mi>1</span><span class=p>}</span></code> will be treated as equal.</li> </ul> <h3 id=key-order>Key order<a class=headerlink href=#key-order title="Permanent link">¶</a></h3> <p>The order in which name/value pairs are added to the object is <em>not</em> preserved by the library. Therefore, iterating an object may return name/value pairs in a different order than they were originally stored. In fact, keys will be traversed in alphabetical order as <code>std::map</code> with <code>std::less</code> is used by default. Please note this behavior conforms to <a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a>, because any order implements the specified "unordered" nature of <abbr title="JavaScript Object Notation">JSON</abbr> objects.</p> <h3 id=limits>Limits<a class=headerlink href=#limits title="Permanent link">¶</a></h3> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 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 <code>max_size</code> function of a <abbr title="JavaScript Object Notation">JSON</abbr> object.</p> <h3 id=storage_1>Storage<a class=headerlink href=#storage_1 title="Permanent link">¶</a></h3> <p>Objects are stored as pointers in a <code>basic_json</code> type. That is, for any access to obLine truncated
|
||||
<span class=n>json</span><span class=w> </span><span class=n>j</span><span class=w> </span><span class=o>=</span><span class=w> </span><span class=n>m</span><span class=p>;</span>
|
||||
<span class=c1>// j is [[1,"one"],[2,"two"]], not {"1":"one","2":"two"}</span>
|
||||
</code></pre></div> <h2 id=arrays>Arrays<a class=headerlink href=#arrays title="Permanent link">¶</a></h2> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> describes <abbr title="JavaScript Object Notation">JSON</abbr> arrays as follows:</p> <blockquote> <p>An array is an ordered sequence of zero or more values.</p> </blockquote> <h3 id=default-type_1>Default type<a class=headerlink href=#default-type_1 title="Permanent link">¶</a></h3> <p>With the default values for <em>ArrayType</em> (<code>std::vector</code>) and <em>AllocatorType</em> (<code>std::allocator</code>), the default value for <code>array_t</code> is:</p> <div class=highlight><pre><span></span><code><span class=n>std</span><span class=o>::</span><span class=n>vector</span><span class=o><</span>
|
||||
</code></pre></div> <h2 id=arrays>Arrays<a class=headerlink href=#arrays title="Permanent link">¶</a></h2> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> describes <abbr title="JavaScript Object Notation">JSON</abbr> arrays as follows:</p> <blockquote> <p>An array is an ordered sequence of zero or more values.</p> </blockquote> <h3 id=default-type_1>Default type<a class=headerlink href=#default-type_1 title="Permanent link">¶</a></h3> <p>With the default values for <em>ArrayType</em> (<code>std::vector</code>) and <em>AllocatorType</em> (<code>std::allocator</code>), the default type for <code>array_t</code> is:</p> <div class=highlight><pre><span></span><code><span class=n>std</span><span class=o>::</span><span class=n>vector</span><span class=o><</span>
|
||||
<span class=w> </span><span class=n>basic_json</span><span class=p>,</span><span class=w> </span><span class=c1>// value_type</span>
|
||||
<span class=w> </span><span class=n>std</span><span class=o>::</span><span class=n>allocator</span><span class=o><</span><span class=n>basic_json</span><span class=o>></span><span class=w> </span><span class=c1>// allocator_type</span>
|
||||
<span class=o>></span>
|
||||
</code></pre></div> <h3 id=limits_1>Limits<a class=headerlink href=#limits_1 title="Permanent link">¶</a></h3> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> specifies:</p> <blockquote> <p>An implementation may set limits on the maximum depth of nesting.</p> </blockquote> <p>In this class, the array'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 <code>max_size</code> function of a <abbr title="JavaScript Object Notation">JSON</abbr> array.</p> <h3 id=storage_2>Storage<a class=headerlink href=#storage_2 title="Permanent link">¶</a></h3> <p>Arrays are stored as pointers in a <code>basic_json</code> type. That is, for any access to array values, a pointer of type <code>array_t*</code> must be dereferenced.</p> <h2 id=strings>Strings<a class=headerlink href=#strings title="Permanent link">¶</a></h2> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> describes <abbr title="JavaScript Object Notation">JSON</abbr> strings as follows:</p> <blockquote> <p>A string is a sequence of zero or more Unicode characters.</p> </blockquote> <p>Unicode values are split by the <abbr title="JavaScript Object Notation">JSON</abbr> class into byte-sized characters during deserialization.</p> <h3 id=default-type_2>Default type<a class=headerlink href=#default-type_2 title="Permanent link">¶</a></h3> <p>With the default values for <em>StringType</em> (<code>std::string</code>), the default value for <code>string_t</code> is <code class=highlight><span class=n>std</span><span class=o>::</span><span class=n>string</span></code>.</p> <h3 id=encoding>Encoding<a class=headerlink href=#encoding title="Permanent link">¶</a></h3> <p>Strings are stored in <abbr title="Unicode Transformation Format">UTF</abbr>-8 encoding. Therefore, functions like <code>std::string::size()</code> or <code>std::string::length()</code> return the number of <strong>bytes</strong> in the string rather than the number of characters or glyphs.</p> <h3 id=string-comparison>String comparison<a class=headerlink href=#string-comparison title="Permanent link">¶</a></h3> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> states:</p> <blockquote> <p>Software implementations are typically required to test names of object members for equality. Implementations that transform the textual representation into sequences of Unicode code units and then perform the comparison numerically, code unit by code unit are interoperable in the sense that implementations will agree in all cases on equality or inequality of two strings. For example, implementations that compare strings with escaped characters unconverted may incorrectly find that <code>"a\\b"</code> and <code>"a\u005Cb"</code> are not equal.</p> </blockquote> <p>This implementation is interoperable as it does compare strings code unit by code unit.</p> <h3 id=storage_3>Storage<a class=headerlink href=#storage_3 title="Permanent link">¶</a></h3> <p>String values are stored as pointers in a <code>basic_json</code> type. That is, for any access to string values, a pointer of type <code>string_t*</code> must be dereferenced.</p> <h2 id=booleans>Booleans<a class=headerlink href=#booleans title="Permanent link">¶</a></h2> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> implicitly describes a boolean as a type which differentiates the two literals <code>true</code> and <code>false</code>.</p> <h3 id=default-type_3>Default type<a class=headerlink href=#default-type_3 title="Permanent link">¶</a></h3> <p>With the default values for <em>BooleanType</em> (<code class=highlight><span class=kt>bool</span></code>), the default value for <code>boolean_t</code> is <code class=highlight><span class=kt>bool</span></code>.</p> <h3 id=storage_4>Storage<a class=headerlink href=#storage_4 title="Permanent link">¶</a></h3> <p>Boolean values are stored directly inside a <code>basic_json</code> type.</p> <h2 id=numbers>Numbers<a class=headerlink href=#numbers title="Permanent link">¶</a></h2> <p>See the <a href=number_handling/ >number handling</a> article for a detailed discussion on how numbers are handled by this library.</p> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> describes numbers as follows:</p> <blockquote> <p>The representation of numbers is similar to that used in most programming languages. A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. Leading zeros are not allowed. (...) Numeric values that cannot be reprLine truncated
|
||||
</code></pre></div> <h3 id=limits_1>Limits<a class=headerlink href=#limits_1 title="Permanent link">¶</a></h3> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> specifies:</p> <blockquote> <p>An implementation may set limits on the maximum depth of nesting.</p> </blockquote> <p>In this class, the array'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 <code>max_size</code> function of a <abbr title="JavaScript Object Notation">JSON</abbr> array.</p> <h3 id=storage_2>Storage<a class=headerlink href=#storage_2 title="Permanent link">¶</a></h3> <p>Arrays are stored as pointers in a <code>basic_json</code> type. That is, for any access to array values, a pointer of type <code>array_t*</code> must be dereferenced.</p> <h2 id=strings>Strings<a class=headerlink href=#strings title="Permanent link">¶</a></h2> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> describes <abbr title="JavaScript Object Notation">JSON</abbr> strings as follows:</p> <blockquote> <p>A string is a sequence of zero or more Unicode characters.</p> </blockquote> <p>Unicode values are split by the <abbr title="JavaScript Object Notation">JSON</abbr> class into byte-sized characters during deserialization.</p> <h3 id=default-type_2>Default type<a class=headerlink href=#default-type_2 title="Permanent link">¶</a></h3> <p>With the default values for <em>StringType</em> (<code>std::string</code>), the default type for <code>string_t</code> is <code class=highlight><span class=n>std</span><span class=o>::</span><span class=n>string</span></code>.</p> <h3 id=encoding>Encoding<a class=headerlink href=#encoding title="Permanent link">¶</a></h3> <p>Strings are stored in <abbr title="Unicode Transformation Format">UTF</abbr>-8 encoding. Therefore, functions like <code>std::string::size()</code> or <code>std::string::length()</code> return the number of <strong>bytes</strong> in the string rather than the number of characters or glyphs.</p> <h3 id=string-comparison>String comparison<a class=headerlink href=#string-comparison title="Permanent link">¶</a></h3> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> states:</p> <blockquote> <p>Software implementations are typically required to test names of object members for equality. Implementations that transform the textual representation into sequences of Unicode code units and then perform the comparison numerically, code unit by code unit are interoperable in the sense that implementations will agree in all cases on equality or inequality of two strings. For example, implementations that compare strings with escaped characters unconverted may incorrectly find that <code>"a\\b"</code> and <code>"a\u005Cb"</code> are not equal.</p> </blockquote> <p>This implementation is interoperable as it does compare strings code unit by code unit.</p> <h3 id=storage_3>Storage<a class=headerlink href=#storage_3 title="Permanent link">¶</a></h3> <p>String values are stored as pointers in a <code>basic_json</code> type. That is, for any access to string values, a pointer of type <code>string_t*</code> must be dereferenced.</p> <h2 id=booleans>Booleans<a class=headerlink href=#booleans title="Permanent link">¶</a></h2> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> implicitly describes a boolean as a type which differentiates the two literals <code>true</code> and <code>false</code>.</p> <h3 id=default-type_3>Default type<a class=headerlink href=#default-type_3 title="Permanent link">¶</a></h3> <p>With the default values for <em>BooleanType</em> (<code class=highlight><span class=kt>bool</span></code>), the default type for <code>boolean_t</code> is <code class=highlight><span class=kt>bool</span></code>.</p> <h3 id=storage_4>Storage<a class=headerlink href=#storage_4 title="Permanent link">¶</a></h3> <p>Boolean values are stored directly inside a <code>basic_json</code> type.</p> <h2 id=numbers>Numbers<a class=headerlink href=#numbers title="Permanent link">¶</a></h2> <p>See the <a href=number_handling/ >number handling</a> article for a detailed discussion on how numbers are handled by this library.</p> <p><a href="https://tools.ietf.org/html/rfc8259"><abbr title="Request for Comments">RFC</abbr> 8259</a> describes numbers as follows:</p> <blockquote> <p>The representation of numbers is similar to that used in most programming languages. A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. Leading zeros are not allowed. (...) Numeric values that cannot be represLine truncated
|
||||
Reference in new issue
Block a user