</code></pre></div><p>yield different results (<codeclass=highlight><spanclass=p>[</span><spanclass=kc>true</span><spanclass=p>]</span></code> vs. <codeclass=highlight><spanclass=kc>true</span></code>)?</p></div><p>This is a known issue, and -- even worse -- the behavior differs between GCC and Clang. The "culprit" for this is the library's constructor overloads for initializer lists to allow syntax like</p><divclass=highlight><pre><span></span><code><spanclass=n>json</span><spanclass=w></span><spanclass=n>array</span><spanclass=w></span><spanclass=o>=</span><spanclass=w></span><spanclass=p>{</span><spanclass=mi>1</span><spanclass=p>,</span><spanclass=w></span><spanclass=mi>2</span><spanclass=p>,</span><spanclass=w></span><spanclass=mi>3</span><spanclass=p>,</span><spanclass=w></span><spanclass=mi>4</span><spanclass=p>};</span>
</code></pre></div><p>for objects.</p><divclass="admonition tip"><pclass=admonition-title>Tip</p><p>To avoid any confusion and ensure portable code, <strong>do not</strong> use brace initialization with the types <code>basic_json</code>, <code>json</code>, or <code>ordered_json</code> unless you want to create an object or array as shown in the examples above.</p></div><h2id=limitations>Limitations<aclass=headerlinkhref=#limitationstitle="Permanent link">¶</a></h2><h3id=relaxed-parsing>Relaxed parsing<aclass=headerlinkhref=#relaxed-parsingtitle="Permanent link">¶</a></h3><divclass="admonition question"><pclass=admonition-title>Question</p><p>Can you add an option to ignore trailing commas?</p></div><p>This library does not support any feature which would jeopardize interoperability.</p><h3id=parse-errors-reading-non-ascii-characters>Parse errors reading non-ASCII characters<aclass=headerlinkhref=#parse-errors-reading-non-ascii-characterstitle="Permanent link">¶</a></h3><divclass="admonition question"><pclass=admonition-title>Questions</p><ul><li>Why is the parser complaining about a Chinese character?</li><li>Does the library support Unicode?</li><li>I get an exception <code>[json.exception.parse_error.101] parse error at line 1, column 53: syntax error while parsing value - invalid string: ill-formed UTF-8 byte; last read: '"Testé$')"</code></li></ul></div><p>The library supports <strong>Unicode input</strong> as follows:</p><ul><li>Only <strong>UTF-8</strong> encoded input is supported which is the default encoding for JSON according to <ahref=https://tools.ietf.org/html/rfc8259.html#section-8.1>RFC 8259</a>.</li><li><code>std::u16string</code> and <code>std::u32string</code> can be parsed, assuming UTF-16 and UTF-32 encoding, respectively. These encodings are not supported when reading from files or other input containers.</li><li>Other encodings such as Latin-1 or ISO 8859-1 are <strong>not</strong> supported and will yield parse or serialization errors.</li><li><ahref=http://www.unicode.org/faq/private_use.html#nonchar1>Unicode noncharacters</a> will not be replaced by the library.</li><li>Invalid surrogates (e.g., incomplete pairs such as <code>\uDEAD</code>) will yield parse errors.</li><li>The strings stored in the library are UTF-8 encoded. When using the default string type (<code>std::string</code>), note that its length/size functions return the number of stored bytes rather than the number of characters or glyphs.</li><li>When you store strings with different encodings in the library, calling <ahref=https://nlohmann.github.io/json/classnlohmann_1_1basic__json_a50ec80b02d0f3f51130d4abb5d1cfdc5.html#a50ec80b02d0f3f51130d4abb5d1cfdc5><code>dump()</code></a> may throw an exception unless <code>json::error_handler_t::replace</code> or <code>json::error_handler_t::ignore</code> are used as error handlers.</li></ul><p>In most cases, the parser is right to complain, because the input is not UTF-8 encoded. This is especially true for Microsoft Windows where Latin-1 or ISO 8859-1 is often the standard encoding.</p><h3id=wide-string-handling>Wide string handling<aclass=headerlinkhref=#wide-string-handlingtitle="Permanent link">¶</a></h3><divclass="admonition question"><pclass=admonition-title>Question</p><p>Why are wide strings (e.g., <code>std::wstring</code>) dumped as arrays of numbers?</p></div><p>As described <ahref=#parse-errors-reading-non-ascii-characters>above</a>, the library assumes UTF-8 as encoding. To store a wide string, you need to change the encoding.</p><divclass="admonition example"><pclass=admonition-title>Example</p><divclass=highlight><pre><span></span><code><spanclass=cp>#include</span><spanclass=w></span><spanclass=cpf><codecvt></span><spanclass=c1> // codecvt_utf8</span>
</code></pre></div></div><h2id=exceptions>Exceptions<aclass=headerlinkhref=#exceptionstitle="Permanent link">¶</a></h2><h3id=parsing-without-exceptions>Parsing without exceptions<aclass=headerlinkhref=#parsing-without-exceptionstitle="Permanent link">¶</a></h3><divclass="admonition question"><pclass=admonition-title>Question</p><p>Is it possible to indicate a parse error without throwing an exception?</p></div><p>Yes, see <ahref=../../features/parsing/parse_exceptions/>Parsing and exceptions</a>.</p><h3id=key-name-in-exceptions>Key name in exceptions<aclass=headerlinkhref=#key-name-in-exceptionstitle="Permanent link">¶</a></h3><divclass="admonition question"><pclass=admonition-title>Question</p><p>Can I get the key of the object item that caused an exception?</p></div><p>Yes, you can. Please define the symbol <ahref=../../api/macros/json_diagnostics/><code>JSON_DIAGNOSTICS</code></a> to get <ahref=../exceptions/#extended-diagnostic-messages>extended diagnostics messages</a>.</p><h2id=serialization-issues>Serialization issues<aclass=headerlinkhref=#serialization-issuestitle="Permanent link">¶</a></h2><h3id=number-precision>Number precision<aclass=headerlinkhref=#number-precisiontitle="Permanent link">¶</a></h3><divclass="admonition question"><pclass=admonition-title>Question</p><ul><li>It seems that precision is lost when serializing a double.</li><li>Can I change the precision for floating-point serialization?</li></ul></div><p>The library uses <code>std::numeric_limits<number_float_t>::digits10</code> (15 for IEEE <code>double</code>s) digits for serialization. This value is sufficient to guarantee roundtripping. If one uses more than this number of digits of precision, then string -> value -> string is not guaranteed to round-trip.</p><divclass="admonition quote"><pclass=admonition-title><ahref=https://en.cppreference.com/w/cpp/types/numeric_limits/digits10>cppreference.com</a></p><p>The value of <code>std::numeric_limits<T>::digits10</code> is the number of base-10 digits that can be represented by the type T without change, that is, any number with this many significant decimal digits can be converted to a value of type T and back to decimal form, without change due to rounding or overflow. </p></div><divclass="admonition tip"><pclass=admonition-title>Tip</p><p>The website <ahref=https://float.exposed>https://float.exposed</a> gives a good insight into the internal storage of floating-point numbers.</p></div><p>See <ahref=../../features/types/number_handling/#number-serialization>this section</a> on the library's number handling for more information.</p><h2id=compilation-issues>Compilation issues<aclass=headerlinkhref=#compilation-issuestitle="Permanent link">¶</a></h2><h3id=android-sdk>Android SDK<aclass=headerlinkhref=#android-sdktitle="Permanent link">¶</a></h3><divclass="admonition question"><pclass=admonition-title>Question</p><p>Why does the code not compile with Android SDK?</p></div><p>Android defaults to using very old compilers and C++ libraries. To fix this, add the following to your <code>Application.mk</code>. This will switch to the LLVM C++ library, the Clang compiler, and enable C++11 and other features disabled by default.</p><divclass=highlight><pre><span></span><code><spanclass=na>APP_STL</span><spanclass=w></span><spanclass=o>:</span><spanclass=s>= c++_shared</span>
