Fix documentation gaps found in a full GitHub Discussions review (#5264)

* 📝 Fix documentation gaps found in a full GitHub Discussions review Reviewed all 1008 GitHub Discussions (2020-2026) for recurring questions that better or more visible documentation would have avoided. Adds/expands documentation for ~26 distinct gaps, including: - New "Debugging" page collecting natvis, GDB pretty printer, LLDB status, and JSON_DIAGNOSTICS pointers (previously scattered/undiscoverable) - Thread-safety and schema-validation FAQ entries - StringType's char-based requirement (no wstring/u16string/u32string) - Brace-initialization-yields-arrays warning directly on the constructor reference page (previously only in the FAQ, missed by users reading the constructor docs) - std::any exclusion from get<T>(), with a manual-dispatch example - Non-string-keyed std::map serializing as an array of pairs - ordered_json compatibility with NLOHMANN_DEFINE_TYPE_* macros (already worked, was undocumented) - std::array truncation on size-mismatched conversion (no exception) - static_cast vs. get<std::optional<T>>() divergence - Recipe for omitting a std::optional field instead of emitting null - No built-in nesting-depth limit during parsing + a callback-based workaround recipe - Recipe for streaming a large homogeneous array via parser callbacks - operator>> stream-position semantics for concatenated JSON values - JSON Pointer array-vs-object creation rule for non-existing paths - CMake target name (nlohmann_json_modules) needed to link C++20 modules - ESP-IDF/PlatformIO: no official package, link to a community fork - get(key, default) as the Python dict.get() equivalent - reserve() recipe for pre-allocating array capacity - JSONC as an alias for the existing ignore_comments/ignore_trailing_commas combination (distinct from the unsupported JSON5) - items() dereferenced-element type: decltype() idiom + detail-namespace stability caveat - Various macro/type-conversion limitations (MSGPACK_DEFINE_ARRAY equivalent, char-array round-tripping, ADL serializer macro gap) Signed-off-by: Niels Lohmann <mail@nlohmann.me> * 🎨 fix format Signed-off-by: Niels Lohmann <mail@nlohmann.me> --------- Signed-off-by: Niels Lohmann <mail@nlohmann.me>
2026-09-01 14:07:14 +00:00 · 2026-07-10 16:01:08 +02:00
parent b630f5e9c7
commit e9c3985f0a
23 changed files with 367 additions and 3 deletions
@@ -180,6 +180,49 @@ For _derived_ classes and structs, use the following macros
    }
    ```

+!!! warning "Overriding conversions for natively-supported types"
+
+    The library already provides built-in `to_json`/`from_json` conversions for STL containers such as
+    `std::vector`, `std::array`, and `std::map`. Defining your own free-function `to_json`/`from_json` overload
+    for one of these container types directly (instead of for your own type) can conflict with the built-in
+    overload during overload resolution, producing compiler errors ("no matching overloaded function",
+    "call is ambiguous") that vary by compiler and library version. If you need different conversion behavior
+    for a container type the library already handles, wrap it in your own type (or use `adl_serializer`
+    specialization, as shown [above](#how-do-i-convert-third-party-types) for `boost::optional`) instead of
+    trying to re-specialize `to_json`/`from_json` for the container type itself.
+
+!!! warning "Raw C-style arrays"
+
+    Members declared as raw C-style arrays (e.g., `char buf[1024]`) do not round-trip safely through
+    `NLOHMANN_DEFINE_TYPE_*` macros or the default (de)serializers: `to_json` serializes any `char` array as a
+    JSON *string* (matching the `std::string`-constructible overload), but the `from_json` overload for
+    fixed-size arrays expects a JSON *array* and iterates it element-wise, which fails with a `type_error` when
+    given a string. Use `std::string`, `std::array<char, N>`, or a manually written `to_json`/`from_json` pair
+    for such members instead.
+
+!!! note "Macros and `nlohmann::ordered_json`"
+
+    The `NLOHMANN_DEFINE_TYPE_*`/`NLOHMANN_DEFINE_DERIVED_TYPE_*` macros are generic over any `basic_json`
+    specialization, including `nlohmann::ordered_json`. Simply use `ordered_json` as the target type and members
+    are serialized in declaration order -- no separate macro or extra code is needed.
+
+    ```cpp
+    namespace ns {
+        NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(person, name, address, age)
+    }
+
+    ns::person p{"Ned Flanders", "744 Evergreen Terrace", 60};
+    nlohmann::ordered_json j = p; // keys appear in declaration order: name, address, age
+    ```
+
+!!! note "No macro for non-default-constructible types"
+
+    There is currently no `NLOHMANN_DEFINE_TYPE_*`-style macro for types that are not
+    [DefaultConstructible](https://en.cppreference.com/w/cpp/named_req/DefaultConstructible). This is not an
+    intentional omission of documentation -- no such macro exists yet; see
+    [How can I use `get()` for non-default constructible/non-copyable types?](#how-can-i-use-get-for-non-default-constructiblenon-copyable-types)
+    for the manual pattern to use instead.
+
 ## How do I convert third-party types?

 This requires a bit more advanced technique. But first, let us see how this conversion mechanism works:
@@ -270,6 +313,49 @@ namespace nlohmann {
 }
 ```

+## Why can't I convert to/from `std::any`?
+
+`std::any` is intentionally excluded from `get<T>()`/generic conversion support, so `get<std::any>()` and
+containers like `std::map<std::string, std::any>` fail to compile by design -- there is no way to know, from a
+`json` value alone, which concrete type to store inside the `std::any`. To work with heterogeneous JSON values,
+dispatch on the value's type manually and construct the `std::any` (or extract from it) yourself:
+
+```cpp
+std::any value_to_any(const json& j) {
+    if (j.is_boolean())      { return j.get<bool>(); }
+    if (j.is_number_integer()) { return j.get<int>(); }
+    if (j.is_number_float()) { return j.get<double>(); }
+    if (j.is_string())       { return j.get<std::string>(); }
+    // ... handle other types (arrays, objects) as needed for your use case
+    return {};
+}
+
+json any_to_json(const std::any& a) {
+    if (a.type() == typeid(bool))        { return std::any_cast<bool>(a); }
+    if (a.type() == typeid(int))         { return std::any_cast<int>(a); }
+    if (a.type() == typeid(double))      { return std::any_cast<double>(a); }
+    if (a.type() == typeid(std::string)) { return std::any_cast<std::string>(a); }
+    return nullptr;
+}
+```
+
+## Why does serializing a `std::map`/`std::unordered_map` with non-string keys produce an array?
+
+A `std::map`/`std::unordered_map` whose key type is not string-like (e.g., `std::map<int, std::string>`) is
+serialized as a JSON *array* of 2-element `[key, value]` arrays, not as a JSON object -- JSON object keys must be
+strings, so the library cannot represent an integer-keyed map as an object.
+
+```cpp
+std::map<int, std::string> m{{1, "one"}, {2, "two"}};
+json j = m;
+// j is [[1,"one"],[2,"two"]], not {"1":"one","2":"two"}
+```
+
+## Why does `std::wstring` convert or dump incorrectly?
+
+The library assumes UTF-8 encoding internally, so `std::wstring` is not supported out of the box -- see the FAQ
+entry on [wide string handling](../home/faq.md#wide-string-handling) for why, and for a UTF-8 conversion recipe.
+
 ## Can I write my own serializer? (Advanced use)

 Yes. You might want to take a look at [`unit-udt.cpp`](https://github.com/nlohmann/json/blob/develop/tests/src/unit-udt.cpp) in the test suite, to see a few examples.
@@ -11,7 +11,7 @@ This library does not support comments *by default*. It does so for three reason

 3. It is dangerous for interoperability if some libraries add comment support while others do not. Please check [The Harmful Consequences of the Robustness Principle](https://tools.ietf.org/html/draft-iab-protocol-maintenance-01) on this.

-However, you can set parameter `ignore_comments` to `#!cpp true` in the [`parse`](../api/basic_json/parse.md) function to ignore `//` or `/* */` comments. Comments will then be treated as whitespace.
+However, you can set parameter `ignore_comments` to `#!cpp true` in the [`parse`](../api/basic_json/parse.md) function to ignore `//` or `/* */` comments. Comments will then be treated as whitespace. Combined with `ignore_trailing_commas` (also a `parse` parameter), this covers what is commonly referred to as **JSONC** (JSON with Comments, as used e.g. by Visual Studio Code's `.jsonc` files) -- comments and trailing commas, nothing more. This is a different, smaller extension than [JSON5](https://json5.org), which additionally allows unquoted keys, single-quoted strings, and other syntax changes that this library does not support.

 For more information, see [JSON With Commas and Comments (JWCC)](https://nigeltao.github.io/blog/2021/json-with-commas-comments.html).

@@ -84,6 +84,49 @@ which forces the explicit `get` form and can catch unintended conversions at com
    j_null.get_to(opt);                                     // ✅ std::nullopt
    ```

+!!! warning "`static_cast` and `get<std::optional<T>>()` are not guaranteed equivalent"
+
+    `operator ValueType()` (used by `static_cast` and implicit conversions) intentionally excludes
+    `std::optional<T>` from delegating to `get<T>()`, to avoid a constructor ambiguity with
+    `std::optional<T>`'s own converting constructor from `basic_json`. As a result,
+    `static_cast<std::optional<T>>(json_value)` goes through `std::optional<T>`'s own converting
+    constructor rather than through `get<std::optional<T>>()`, which can behave differently -- for example,
+    with a custom `adl_serializer<std::optional<T>>` specialization. Prefer `get<std::optional<T>>()`/`get_to()`
+    over `static_cast` for optional types.
+
+!!! warning "Converting to a fixed-size `std::array` does not check length"
+
+    Converting a JSON array to `#!cpp std::array<T, N>` does not check that the JSON array's size matches `N`:
+    if the JSON array is longer, the extra elements are silently dropped; if it is shorter, the remaining
+    `std::array` elements are left default-constructed. No exception is thrown in either case.
+
+    ```cpp
+    json j = {1, 2, 3, 4, 5};
+    auto a = j.get<std::array<int, 3>>();  // {1, 2, 3} -- elements 4 and 5 silently dropped
+    ```
+
+## Omitting a field when serializing `std::optional`
+
+By default, `to_json` for `std::optional<T>` writes either the value or `#!json null` -- there is no built-in way
+to make a field disappear from the serialized object entirely when the `std::optional` is `std::nullopt`. Because
+a specialization of `adl_serializer<std::optional<T>>` only controls how the *value* is converted (it cannot
+prevent the containing object's `to_json` from inserting the key in the first place), omission has to be
+implemented in the *containing* type's `to_json`:
+
+```cpp
+struct person {
+    std::string name;
+    std::optional<int> age;
+};
+
+void to_json(json& j, const person& p) {
+    j = json{{"name", p.name}};
+    if (p.age) {
+        j["age"] = *p.age;  // key is only inserted when the optional has a value
+    }
+}
+```
+
 ## Putting values in

 The reverse direction works the same way: assigning or constructing a `json` from a C++ value converts it to JSON.
@@ -4,7 +4,8 @@

 In many situations, such as configuration files, missing values are not exceptional, but may be treated as if a default
 value was present. For this case, use [`value(key, default_value)`](../../api/basic_json/value.md) which takes the key
-you want to access and a default value in case there is no value stored with that key.
+you want to access and a default value in case there is no value stored with that key. This is equivalent to Python's
+`dict.get(key, default)`.

 ## Example

@@ -102,6 +102,20 @@ that the passed index is the new maximal index. Intermediate values are filled w
    `operator[]` can only be used with objects (with a string argument) or with arrays (with a numeric argument). For
    other types, a [`basic_json::type_error`](../../home/exceptions.md#jsonexceptiontype_error305) is thrown.

+## Performance: reserving array capacity
+
+There is no public `reserve(count)` member on `basic_json` for pre-allocating array capacity. If you are building
+a large array incrementally (e.g., via repeated `push_back()`) and know its final size ahead of time, you can
+reserve capacity via `get_ref()` to access the underlying `array_t` directly:
+
+```cpp
+json j = json::array();
+j.get_ref<json::array_t&>().reserve(1000);
+for (int i = 0; i < 1000; ++i) {
+    j.push_back(i);
+}
+```
+
 ## Summary

 | scenario                          | non-const value                                                                                                                                      | const value                                                                 |
@@ -77,6 +77,11 @@ auto val2 = j.at(json::json_pointer("/nested/three/1"));    // false
 auto val3 = j.value(json::json_pointer("/nested/four"), 0); // 0
 ```

+!!! note "Creating intermediate levels that don't exist"
+
+    See the [`operator[]` notes](../api/basic_json/operator%5B%5D.md#return-value) for how array vs. object is
+    decided when a pointer creates intermediate levels that don't exist yet.
+
 ## Flatten / unflatten

 The library implements a function [`flatten`](../api/basic_json/flatten.md) to convert any JSON document into a JSON
@@ -47,3 +47,6 @@ JSON Lines input with more than one value is treated as invalid JSON by the [`pa
    ```
    
    with a JSON Lines input does not work, because the parser will try to parse one value after the last one.
+
+    This is different from parsing a stream of *concatenated* (non-newline-delimited) JSON values, for which
+    `operator>>` does work -- see its [notes](../../api/operator_gtgt.md#notes) for details.
@@ -58,6 +58,14 @@ table describes the values of the parameters `depth`, `event`, and `parsed`.
    | `array_end`    | 1     | `#!json [52.519444,13.406667]` |
    | `object_end`   | 0     | `#!json {"location":[52.519444,13.406667],"name":"Berlin"}` |

+!!! note "No built-in nesting depth limit"
+
+    The library has no built-in limit on recursion/nesting depth while parsing. A parser callback can only
+    *discard* content it has already parsed (by returning `#!c false`); it cannot make parsing fail once a
+    nesting limit is exceeded partway through reading a deeply nested value. If you need to reject over-deep
+    untrusted input outright, track `depth` in a callback and `throw` from it once your limit is exceeded (a
+    thrown exception propagates out of `parse()` as usual).
+
 ## Return value

 Discarding a value (i.e., returning `#!c false`) has different effects depending on the context in which the function
@@ -112,3 +120,51 @@ This approach has two limitations:

 For strict validation with precise error positions, implementing a [SAX interface](sax_interface.md) instead gives
 access to the parser's position information directly.
+
+## Recipe: streaming a large homogeneous array
+
+A common use case is a huge top-level array of many similarly-shaped objects, too large to hold entirely in
+memory as a `#!c json` value. A parser callback can hand off each completed element to a user function and then
+discard it, so memory usage stays bounded by a single element (plus the not-yet-parsed tail of the input) rather
+than the whole document. Since the top-level array's `array_start`/`array_end` are reported at `depth == 0` (its
+parent is the document root), the object elements it contains are reported at `depth == 1`:
+
+??? example
+
+    ```cpp
+    std::ifstream input("large_array.json");
+
+    auto callback = [](int depth, json::parse_event_t event, json& parsed) -> bool {
+        if (depth == 1 && event == json::parse_event_t::object_end) {
+            handle_element(parsed); // process the element, e.g. write it elsewhere
+            return false;           // discard it -- frees its memory before the next one is parsed
+        }
+        return true; // keep everything else, including the (by then empty) top-level array
+    };
+
+    json::parse(input, callback);
+    ```
+
+If the array's elements are scalars or nested arrays instead of objects, check for `parse_event_t::value` or
+`parse_event_t::array_end` at `depth == 1` instead. The same approach works for a top-level *object* of many
+homogeneous values by checking `object_end`/`value` events at `depth == 1` there too.
+
+## Recipe: max nesting depth via a callback
+
+Since there is no built-in nesting-depth limit (see the note above), a callback can enforce one manually by
+tracking the maximum `depth` seen and throwing once it is exceeded:
+
+??? example
+
+    ```cpp
+    constexpr int max_depth = 32;
+
+    auto callback = [](int depth, json::parse_event_t /*event*/, json& /*parsed*/) -> bool {
+        if (depth > max_depth) {
+            throw std::runtime_error("maximum nesting depth exceeded");
+        }
+        return true;
+    };
+
+    json::parse(input, callback);
+    ```
@@ -151,6 +151,18 @@ In this class, the object's limit of nesting is not explicitly constrained. Howe

 Objects are stored as pointers in a `basic_json` type. That is, for any access to object values, a pointer of type `object_t*` must be dereferenced.

+### Converting maps with non-string keys
+
+A `std::map`/`std::unordered_map` whose key type is not string-like (e.g., `std::map<int, std::string>`) is
+converted to a JSON *array* of 2-element `[key, value]` arrays rather than a JSON object, because JSON object
+keys must be strings:
+
+```cpp
+std::map<int, std::string> m{{1, "one"}, {2, "two"}};
+json j = m;
+// j is [[1,"one"],[2,"two"]], not {"1":"one","2":"two"}
+```
+

 ## Arrays