Call alloc_nodes() before reading chunks.back() in the json_view chunk test

The operands of == are unsequenced, and MSVC evaluated d->edits->chunks.back() before alloc_nodes() added the new chunk, so the check compared the result with the previous chunk and failed on msvc-arm64 (Debug and Release). Signed-off-by: Niels Lohmann <mail@nlohmann.me>
Address the rest of the review of editable json documents
2026-11-15 16:16:42 +00:00 · 2026-10-20 22:27:02 +02:00 · 2026-10-20 22:27:01 +02:00 · 2026-10-20 22:27:00 +02:00 · 2026-10-20 22:26:59 +02:00 · 2026-10-20 22:26:59 +02:00
174 changed files with 1277 additions and 80905 deletions
@@ -63,7 +63,7 @@ labels:
    - "single_include/nlohmann/json_view\\.hpp"
    - "tests/src/unit-json_view.*"
    - "tests/src/json_view_test_helpers\\.hpp"
-    - "tests/src/fuzzer-(parse_json_view|json_view_image)\\.cpp"
+    - "tests/src/fuzzer-parse_json_view\\.cpp"
    - "tools/amalgamate/config_json_view\\.json"
    - "docs/mkdocs/docs/features/json_view\\.md"
    - "docs/mkdocs/docs/api/basic_json_(document|view)/.*"
@@ -77,12 +77,13 @@ jobs:
          cd $MAIN_DIR

          # Built from this PR's own tools/macro_builder/main.cpp, not a
-          # develop checkout: unlike amalgamate.py, this tool has no other
-          # source of truth to check against (its own README documents that
-          # it must reproduce macro_scope.hpp byte for byte), so there is
-          # nothing to gain from checking out a separate copy, and doing so
-          # would make this step fail on a PR that adds support for a new
-          # dispatch table until that PR itself merges to develop.
+          # develop checkout: unlike amalgamate.py and generate_natvis.py,
+          # this tool has no other source of truth to check against (its
+          # own README documents that it must reproduce macro_scope.hpp
+          # byte for byte), so there is nothing to gain from checking out a
+          # separate copy, and doing so would make this step fail on a PR
+          # that adds support for a new dispatch table until that PR itself
+          # merges to develop.
          TMPDIR=$(mktemp -d ./macro_builder_check.XXXXXX)
          c++ -std=c++11 tools/macro_builder/main.cpp -o "$TMPDIR/macro_builder"
          "$TMPDIR/macro_builder" > "$TMPDIR/paste.hpp"
@@ -145,14 +146,14 @@ jobs:
      - name: Regenerate nlohmann_json.natvis
        run: |
          cd $MAIN_DIR
-          # The generator and its template are what this check verifies the
-          # committed natvis file against (which namespaces it lists, and
-          # what each entry looks like), so run this PR's copy rather than
-          # the develop checkout's: with develop's, a PR that changes either
-          # could never pass. generate_natvis.py loads the template from its
-          # own directory. Like the macro_builder step above, this only runs
-          # PR content in a job without credentials.
-          python3 tools/generate_natvis/generate_natvis.py $MAIN_DIR
+          # The template is what this check verifies the committed natvis
+          # file against, so take it from this PR rather than from the
+          # develop checkout: generate_natvis.py loads the template from its
+          # own directory, and with develop's copy a PR that changes the
+          # template could never pass. Like the macro_builder step above,
+          # this only renders PR content in a job without credentials.
+          cp tools/generate_natvis/nlohmann_json.natvis.j2 $NATVIS_TOOL_DIR/
+          python3 $NATVIS_TOOL_DIR/generate_natvis.py $MAIN_DIR

      - name: Build patch and check for differences
        id: diff
@@ -1,81 +0,0 @@
-name: "Check API documentation"
-
-on:
-  pull_request:
-
-permissions:
-  contents: read
-
-jobs:
-  check_api_docs:
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: Harden Runner
-        uses: step-security/harden-runner@bf7454d06d71f1098171f2acdf0cd4708d7b5920 # v2.20.0
-        with:
-          egress-policy: audit
-
-      - name: Checkout pull request
-        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
-
-      - name: Install clang
-        # Used only as a subprocess for `clang++ -E -v` system-include-path discovery in
-        # extract_api.py; it does not need to version-match the pinned libclang pip wheel
-        # below, which does the actual AST parsing. Do not "fix" this to be version-matched.
-        run: sudo apt-get update && sudo apt-get install -y clang
-
-      - name: Install Python dependencies
-        run: pip install -r tools/api_checker/requirements.txt
-
-      - name: Extract API and regenerate the committed surface file
-        run: |
-          python3 tools/api_checker/extract_api.py \
-            --header include/nlohmann/json.hpp \
-            --include include \
-            --output /tmp/api_snapshot.json \
-            --surface-output tools/api_checker/api_surface.json
-
-      - name: "Check API documentation (Phase 1: advisory)"
-        # Surfaces missing/broken @sa links without failing the job while the backlog from the
-        # initial AST-based rollout is burned down. See tools/api_checker/POLICY.md and the PR
-        # that introduced this workflow for the two-phase rollout plan.
-        continue-on-error: true
-        run: |
-          python3 tools/api_checker/check_docs.py \
-            --snapshot /tmp/api_snapshot.json
-
-      - name: Check macro documentation (advisory only)
-        # Cross-checks docs/mkdocs/docs/api/macros/ pages against #define sites. Only checks the
-        # documented-macro-still-exists direction; never blocks CI. See POLICY.md.
-        run: python3 tools/api_checker/check_macros.py
-
-      - name: Check for uncommitted API surface changes
-        id: diff
-        run: |
-          mkdir -p ${{ github.workspace }}/patch
-          git diff --patch --no-color -- tools/api_checker/api_surface.json > ${{ github.workspace }}/patch/api_surface.patch
-          if [ -s ${{ github.workspace }}/patch/api_surface.patch ]; then
-            echo "tools/api_checker/api_surface.json is out of date. Diff:"
-            cat ${{ github.workspace }}/patch/api_surface.patch
-            echo "has_diff=true" >> "$GITHUB_OUTPUT"
-          else
-            echo "has_diff=false" >> "$GITHUB_OUTPUT"
-          fi
-
-      # Uploaded so contributors can fix their PR with `git apply api_surface.patch`
-      # instead of installing libclang locally.
-      - name: Upload patch
-        if: steps.diff.outputs.has_diff == 'true'
-        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
-        with:
-          name: api-surface-patch
-          path: patch/api_surface.patch
-
-      - name: Fail if API surface file is not up to date
-        # Unlike the doc-backlog check above, this is purely mechanical regeneration with no
-        # backlog to phase in -- blocking from the start, matching check_amalgamation.yml's
-        # precedent. Contributors who add/remove/rename public API must regenerate and commit
-        # tools/api_checker/api_surface.json as part of their PR.
-        if: steps.diff.outputs.has_diff == 'true'
-        run: exit 1
@@ -50,7 +50,7 @@ jobs:
          persist-credentials: false

      - name: "Run analysis"
-        uses: ossf/scorecard-action@fa7117db83c52d787ae5a89f350999701505d78e # v2.5.0
+        uses: ossf/scorecard-action@2d1146689b8cda280b9bc96326124645441f03bc # v2.4.4
        with:
          results_file: results.sarif
          results_format: sarif
@@ -3,7 +3,6 @@
 *.gcno
 *.gcda
 .DS_Store
-__pycache__/

 /.idea
 /cmake-build-*
@@ -45,10 +44,6 @@ venv

 nlohmann_json.spdx

-# api_checker: ephemeral, location/doc-status-sensitive working file (not the committed
-# release-tracking artifact -- see tools/api_checker/api_surface.json for that)
-/tools/api_checker/api_snapshot.json
-
 # Bazel-related
 MODULE.bazel.lock

@@ -73,7 +73,6 @@ cc_library(
        "include/nlohmann/detail/view/edit.hpp",
        "include/nlohmann/detail/view/edit_storage.hpp",
        "include/nlohmann/detail/view/errors.hpp",
-        "include/nlohmann/detail/view/image.hpp",
        "include/nlohmann/detail/view/input.hpp",
        "include/nlohmann/detail/view/iterator.hpp",
        "include/nlohmann/detail/view/lookup.hpp",
@@ -105,7 +105,7 @@ Thanks everyone!

 :books: If you want to **learn more** about how to use the library, check out the rest of the [**README**](#examples), have a look at [**code examples**](https://github.com/nlohmann/json/tree/develop/docs/mkdocs/docs/examples), or browse through the [**help pages**](https://json.nlohmann.me).

-:construction: If you want to understand the **API** better, check out the [**API Reference**](https://json.nlohmann.me/api/basic_json/) or have a look at the [quick reference](#quick-reference) below. The public API surface is derived mechanically and checked for documentation coverage by the tooling in [`tools/api_checker/`](tools/api_checker/), whose [POLICY.md](tools/api_checker/POLICY.md) defines what counts as public API and what stability is guaranteed.
+:construction: If you want to understand the **API** better, check out the [**API Reference**](https://json.nlohmann.me/api/basic_json/) or have a look at the [quick reference](#quick-reference) below.

 :bug: If you found a **bug**, please check the [**FAQ**](https://json.nlohmann.me/home/faq/) if it is a known issue or the result of a design decision. Please also have a look at the [**issue list**](https://github.com/nlohmann/json/issues) before you [**create a new issue**](https://github.com/nlohmann/json/issues/new/choose). Please provide as much information as possible to help us understand and reproduce your issue.

@@ -1 +1 @@
-cppcheck==1.5.3
+cppcheck==1.5.2
@@ -485,10 +485,8 @@ basic_json(basic_json&& other) noexcept;
 1. Since version 1.0.0.
 2. Since version 1.0.0.
 3. Since version 2.1.0.
-4. Since version 3.2.0. Also initializes the position reported by
-   [`start_pos()`](start_pos.md)/[`end_pos()`](end_pos.md) from `val` when
-   [`JSON_DIAGNOSTIC_POSITIONS`](../macros/json_diagnostic_positions.md) is enabled, since version 3.12.0. Explicit
-   for different string types if `JSON_USE_IMPLICIT_CONVERSIONS` is `0` since version 3.13.0.
+4. Since version 3.2.0. Explicit for different string types if `JSON_USE_IMPLICIT_CONVERSIONS` is `0` since
+   version 3.13.0.
 5. Since version 1.0.0.
 6. Since version 1.0.0.
 7. Since version 1.0.0. Fixed in version 3.13.0 to also check the iterator range for binary values; before, a range
@@ -1,38 +0,0 @@
-# <small>nlohmann::basic_json::</small>bjdata_version_t
-
-```cpp
-enum class bjdata_version_t
-{
-    draft2,
-    draft3,
-};
-```
-
-This enumeration is used in the [`to_bjdata`](to_bjdata.md) function to choose which draft version of
-the BJData specification to encode ND-array extensions for:
-
-draft2
-:   encode using the BJData Draft 2 ND-array format
-
-draft3
-:   encode using the BJData Draft 3 ND-array format
-
-## Examples
-
-??? example
-
-    The example shows how `bjdata_version_t` selects the BJData draft used by `to_bjdata`.
-
-    ```cpp
-    --8<-- "examples/bjdata_version_t.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/bjdata_version_t.output"
-    ```
-
-## Version history
-
- Added in version 3.12.0.
@@ -1,32 +0,0 @@
-# <small>nlohmann::basic_json::</small>initializer_list_t
-
-```cpp
-using initializer_list_t = std::initializer_list<detail::json_ref<basic_json>>;
-```
-
-The type used for the initializer-list [constructor](basic_json.md) (overload 5) and for functions
-such as [`operator=`](operator=.md) that accept a braced-init-list of JSON values. Each element wraps a
-`basic_json` value or something convertible to one, deferring the decision of whether the list should be
-parsed as a JSON array or a JSON object to the constructor itself.
-
-See the [constructor](basic_json.md) documentation for how `initializer_list_t` values are interpreted.
-
-## Examples
-
-??? example
-
-    The example shows how an `initializer_list_t` is used to construct a JSON value.
-
-    ```cpp
-    --8<-- "examples/initializer_list_t.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/initializer_list_t.output"
-    ```
-
-## Version history
-
- Since version 1.0.0.
@@ -1,31 +0,0 @@
-# <small>nlohmann::basic_json::</small>json_sax_t
-
-```cpp
-using json_sax_t = json_sax<basic_json>;
-```
-
-The [`json_sax`](../json_sax/index.md) interface bound to this `basic_json` specialization, i.e. with
-`BasicJsonType` fixed to `basic_json`. Used as the SAX interface type by [`sax_parse`](sax_parse.md) and
-other SAX-based parsing functions.
-
-See [`nlohmann::json_sax`](../json_sax/index.md) for more information.
-
-## Examples
-
-??? example
-
-    The example shows the type `json_sax_t`.
-
-    ```cpp
-    --8<-- "examples/json_sax_t.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/json_sax_t.output"
-    ```
-
-## Version history
-
- Added in version 3.2.0.
@@ -38,7 +38,7 @@ Strong guarantee: `source` and `target` are never modified.

 Linear in the total number of values (including nested ones) in `source` and `target`, times the cost of a key-based
 object operation (looking up a key, or adding one to the patch): logarithmic for [`json`](../json.md), and linear for
-[`ordered_json`](../ordered_json.md) (see [`ordered_map` complexity](../ordered_map/index.md#complexity)). For
+[`ordered_json`](../ordered_json.md) (see [`ordered_map` complexity](../ordered_map.md#complexity)). For
 `ordered_json`, diffing two objects with `n` and `m` members therefore takes O((n+m)²).

 ## Notes
@@ -51,5 +51,3 @@ Linear.
 ## Version history

 - Added in version 1.0.0.
- The `noexcept` specification was extended to also depend on
-  [`json_base_class_t`](json_base_class_t.md)'s move-assignment in version 3.11.3.
@@ -92,8 +92,3 @@ Linear in the size of the JSON value.
 - Since version 1.0.0.
 - Macros `JSON_EXPLICIT`/[`JSON_USE_IMPLICIT_CONVERSIONS`](../macros/json_use_implicit_conversions.md) added
  in version 3.9.0.
- The exclusion of `std::any` from this conversion became conditional on
-  [`JSON_HAS_STATIC_RTTI`](../macros/json_has_static_rtti.md) in version 3.11.3.
- `std::optional<T>` excluded from this conversion in version 3.13.0; use
-  [`get<std::optional<T>>()`](get.md)/[`get_to()`](get_to.md) instead (see
-  [Converting values](../../features/conversions.md)).
@@ -123,6 +123,4 @@ Linear in the size of the JSON value `j`.
  that is not valid UTF-8 unchanged, as before; `strict` (the default if
  [`JSON_STRICT_BINARY_UTF8`](../macros/json_strict_binary_utf8.md) is enabled) throws `type_error.316`.
 - Throws `type_error.321` for a discarded value since version 3.13.0; previously, a discarded value nested in an
-  array or object was silently skipped, producing invalid BJData.
- Writes unsigned integers wider than 64 bits as high-precision numbers since version 3.13.0; previously, they were
-  silently truncated to 64 bits.
+  array or object was silently skipped, producing invalid BJData.
@@ -37,9 +37,8 @@ With (2), the bytes written before the exception remain in the output adapter.

 ## Exceptions

- Throws [out_of_range.407](../../home/exceptions.md#jsonexceptionout_of_range407) if `j` contains an integer outside
-  the range of int64 (an unsigned integer above 9223372036854775807, or, with a number type wider than 64 bits, any
-  integer beyond int64), which BON8 cannot represent
+- Throws [out_of_range.407](../../home/exceptions.md#jsonexceptionout_of_range407) if `j` contains an unsigned integer
+  above 9223372036854775807, which BON8 cannot represent
 - Throws [type_error.316](../../home/exceptions.md#jsonexceptiontype_error316) if `j` contains a string that is not
  valid UTF-8
 - Throws [type_error.321](../../home/exceptions.md#jsonexceptiontype_error321) if `j` or a value nested in it is
@@ -47,10 +47,6 @@ Strong guarantee: if an exception is thrown, there are no changes in the JSON va

 - Throws [`type_error.317`](../../home/exceptions.md#jsonexceptiontype_error317) if the top-level type of the JSON value
  is not an object; example: `"to serialize to BSON, top-level type must be object, but is string"`
- Throws [`out_of_range.407`](../../home/exceptions.md#jsonexceptionout_of_range407) if `j` contains a signed integer
-  outside the range of int64 or an unsigned integer outside the range of uint64, which is only possible with a number
-  type wider than 64 bits; example:
-  `"integer number 9223372036854775808 cannot be represented by BSON as it does not fit int64"`
 - Throws [`out_of_range.409`](../../home/exceptions.md#jsonexceptionout_of_range409) if a key in the JSON object contains
  a null byte (code point U+0000); example: `"BSON key cannot contain code point U+0000 (at byte 2)"`
 - Throws [`out_of_range.412`](../../home/exceptions.md#jsonexceptionout_of_range412) if the length of a document, array,
@@ -123,5 +119,3 @@ pass before anything is written.
  that is not valid UTF-8 unchanged, as before; `strict` (the default if
  [`JSON_STRICT_BINARY_UTF8`](../macros/json_strict_binary_utf8.md) is enabled) throws `type_error.316` before anything
  is written.
- Throws `out_of_range.407` for integers that do not fit 64 bits since version 3.13.0; previously, integers of a
-  number type wider than 64 bits were silently truncated.
@@ -46,9 +46,6 @@ Strong guarantee: if an exception is thrown, there are no changes in the JSON va

 ## Exceptions

- Throws [`out_of_range.407`](../../home/exceptions.md#jsonexceptionout_of_range407) if `j` contains an integer
-  outside [-2^64, 2^64-1], which is only possible with a number type wider than 64 bits; example:
-  `"integer number 18446744073709551616 cannot be represented by CBOR as it does not fit [-2^64, 2^64-1]"`
 - Throws [type_error.316](../../home/exceptions.md#jsonexceptiontype_error316) if a string or object key in `j` is
  not valid UTF-8 and `error_handler` is `strict` (the default only if
  [`JSON_STRICT_BINARY_UTF8`](../macros/json_strict_binary_utf8.md) is enabled)
@@ -93,5 +90,3 @@ Linear in the size of the JSON value `j`.
  [`JSON_STRICT_BINARY_UTF8`](../macros/json_strict_binary_utf8.md) is enabled) throws `type_error.316`.
 - Throws `type_error.321` for a discarded value since version 3.13.0; previously, a discarded value nested in an
  array or object was silently skipped, producing invalid CBOR.
- Throws `out_of_range.407` for integers that do not fit 64 bits since version 3.13.0; previously, integers of a
-  number type wider than 64 bits were silently truncated.
@@ -46,9 +46,6 @@ Strong guarantee: if an exception is thrown, there are no changes in the JSON va

 ## Exceptions

- Throws [`out_of_range.407`](../../home/exceptions.md#jsonexceptionout_of_range407) if `j` contains an integer
-  outside [-2^63, 2^64-1], which is only possible with a number type wider than 64 bits; example:
-  `"integer number 18446744073709551616 cannot be represented by MessagePack as it does not fit [-2^63, 2^64-1]"`
 - Throws [`out_of_range.412`](../../home/exceptions.md#jsonexceptionout_of_range412) if the length of a string, binary
  value, array, or object exceeds 4294967295, the maximum MessagePack can store; example:
  `"MessagePack length 4294967296 exceeds maximum of 4294967295"`
@@ -115,5 +112,3 @@ Linear in the size of the JSON value `j`.
  `number_unsigned_t`.
 - Throws `type_error.321` for a discarded value since version 3.13.0; previously, a discarded value nested in an
  array or object was silently skipped, producing invalid MessagePack.
- Throws `out_of_range.407` for integers that do not fit 64 bits since version 3.13.0; previously, integers of a
-  number type wider than 64 bits were silently truncated.
@@ -49,21 +49,14 @@ bookkeeping edits need, and calling any of them on one fails to compile (`#!cpp

 - **view_type** - the type of view returned by [`root()`](root.md) (`#!cpp basic_json_view<BasicJsonType, Editable>`)
 - **value_t** - the JSON type enumeration, see [`basic_json::value_t`](../basic_json/value_t.md)
- **image_check** - how [`load()`](load.md) validates an image (`full`, `bounds`, `none`), see [`image_check`](load.md#image_check)

 ## Member functions

 - [(constructor)](basic_json_document.md)
-
-### Parsing
-
 - [**parse**](parse.md) (_static_) - deserialize from a compatible input, borrowing or owning it as appropriate
 - [**parse_copy**](parse_copy.md) (_static_) - deserialize a copy of a compatible input
 - [**accept**](accept.md) (_static_) - check whether the input is valid JSON
 - [**read**](read.md) - (re-)parse into this document, reusing its memory
-
-### Access
-
 - [**root**](root.md) - the view of the root value
 - [**is_discarded**](is_discarded.md) - return whether the last parse failed
 - [**source**](source.md) - the parsed text
@@ -71,14 +64,6 @@ bookkeeping edits need, and calling any of them on one fails to compile (`#!cpp
 - [**node_count**](node_count.md) - the number of index entries (values plus object keys)
 - [**memory_usage**](memory_usage.md) - the number of bytes held by the document
 - [**shrink_to_fit**](shrink_to_fit.md) - release unused index capacity
-
-### Images
-
- [**save**](save.md) - the document as an image that `load()` reads without parsing
- [**load**](load.md) (_static_) - read an image written by `save()`
-
-### Edits
-
 - [**set**](set.md) - replace a value, or set an object member, an array element, or the value a JSON pointer refers
  to (`#!cpp Editable` documents only)
 - [**push_back**](push_back.md) - append to an array (`#!cpp Editable` documents only)
@@ -1,179 +0,0 @@
-# <small>nlohmann::basic_json_document::</small>load
-
-```cpp
-// (1)
-static basic_json_document load(const std::uint8_t* image, std::size_t size,
-                                 const image_check check = image_check::full);
-
-// (2)
-static basic_json_document load(const std::vector<std::uint8_t>& image,
-                                 const image_check check = image_check::full);
-
-// (3)
-static basic_json_document load(std::vector<std::uint8_t>&& image,
-                                 const image_check check = image_check::full);
-```
-
-1. Reads an image [`save()`](save.md) wrote, from a pointer and a byte count. The image is **borrowed**: `image`
-   must stay alive and unchanged for as long as the returned document, and any view taken from it, is used.
-2. Reads an image from a `#!cpp std::vector`. Also **borrowed** -- equivalent to overload 1 called with
-   `#!cpp image.data()` and `#!cpp image.size()`.
-3. Reads an image, keeping the vector instead of copying it: `image` is moved into the document (no copy), which
-   then owns it for as long as it needs the text and the decoded strings. [`owns_source()`](owns_source.md) is
-   `#!cpp true` afterward.
-
-In every overload, the node index is copied into storage the document itself owns -- so that it is properly aligned,
-and, for an [editable](index.md#edits) document, can be edited -- while the text and the decoded strings stay in
-`image`. The hash indexes [large objects](../../features/json_view.md) use for lookup are rebuilt, exactly as after
-parsing.
-
-## Parameters
-
-`image` (in)
-:   the image [`save()`](save.md) wrote (overloads 1 and 2), or one to take ownership of (overload 3)
-
-`size` (in)
-:   the number of bytes at `image` (overload 1)
-
-`check` (in)
-:   how thoroughly to validate `image` before trusting it; see [`image_check`](#image_check) below (optional,
-    `#!cpp image_check::full` by default)
-
-## Return value
-
-The document read from the image.
-
-## Exception safety
-
-Overloads 1 and 2 give the strong guarantee: `image` is only read, never written, so a thrown exception leaves the
-caller's buffer untouched.
-
-Overload 3 moves `image` into the document *before* validating it, so that a good image is kept without a copy. If
-loading then fails, the partially built document -- and the vector now inside it -- is discarded along with the
-exception, and `image` itself is left **empty**, not restored to what was passed in. Move a copy in instead, or
-validate with overload 2 first, if the original vector must survive a failed load.
-
-## Exceptions
-
-On a big-endian target, throws [`type_error.320`](../../home/exceptions.md#jsonexceptiontype_error320) -- the same
-exception [`save()`](save.md#exceptions) throws there, since the image format is little-endian only.
-
-Otherwise throws [`parse_error.116`](../../home/exceptions.md#jsonexceptionparse_error116) if `image` is not one
-`save()` could have written, or fails the requested `check`:
-
-| message               | when                                                                                                |
-|------------------------|------------------------------------------------------------------------------------------------------|
-| `too short`            | `image` is `#!cpp nullptr`, or `size` is smaller than the 64-byte header                             |
-| `unknown format`       | the header's magic bytes or version do not match, or a reserved header field is not zero             |
-| `sizes out of range`   | the node count, text size, or decoded-string size the header describes does not fit `size`, or the `#!cpp '\0'` after the text or after the decoded strings is missing |
-| `the check failed`     | `check` is not `#!cpp image_check::none`, and the image fails it -- see [`image_check`](#image_check) |
-
-!!! failure "Example messages"
-
-    ```
-    [json.exception.parse_error.116] parse error: invalid json_document image: too short
-    ```
-    ```
-    [json.exception.parse_error.116] parse error: invalid json_document image: unknown format
-    ```
-    ```
-    [json.exception.parse_error.116] parse error: invalid json_document image: sizes out of range
-    ```
-    ```
-    [json.exception.parse_error.116] parse error: invalid json_document image: the check failed
-    ```
-
-## Complexity
-
-Linear in the number of nodes, which are always copied into the document. `#!cpp image_check::none` does not read
-the text or the decoded strings. `#!cpp image_check::bounds` reads one byte of the text for each float token (its sign,
-to check the recorded digits against the token's length), and nothing else of the text or the decoded strings.
-
-With `#!cpp image_check::full`, linear in the size of the image (the nodes, the text, and the decoded strings), plus
-sorting the ranges of the strings and of the float tokens (at most one per node): the contents of each distinct range
-are checked once, however many nodes refer to it.
-
-## Notes
-
-### `image_check` { #image_check }
-
-```cpp
-using image_check = detail::view::image_check;
-
-enum class image_check
-{
-    full,
-    bounds,
-    none
-};
-```
-
-How thoroughly `load()` validates `image` before trusting it.
-
-`full` (the default)
-:   Checks everything the parser itself guarantees: structure and bounds; that every string is valid UTF-8 (and, for a
-    string still in the source text, that it contains no quote, backslash, or control character); and that every number
-    token is well-formed and matches the value stored for it. Strings and float tokens may share a range only if the
-    ranges are identical (as nodes that share a value do), and never overlap otherwise. Reading and serializing a
-    checked image is safe and always produces valid JSON, exactly as for a parsed document. This is the right choice for
-    an image from anything you do not fully control -- a file, a cache shared with other processes, a peer on the
-    network.
-
-`bounds`
-:   Checks structure and bounds only: that every offset and count in the node index stays inside the image. So
-    `load()`, [`root()`](root.md), element access, and [`materialize()`](../basic_json_view/materialize.md) can never
-    read outside the image, even on a damaged one. It does *not* guarantee that the image describes valid JSON: a
-    string that a `full` check would have rejected can make [`dump()`](../basic_json_view/dump.md) write invalid UTF-8
-    or invalid JSON, or throw [`type_error.316`](../../home/exceptions.md#jsonexceptiontype_error316), and a number can
-    read back with a value that does not match how it is spelled. An [editable document](../json_editable_document.md)
-    does not take such a string over: [`set`](set.md), [`push_back`](push_back.md) and [`insert`](insert.md) throw
-    `type_error.316` when they copy it from a view of the loaded document, and leave the editable document unchanged.
-    `bounds` skips scanning the text and the decoded strings, so it fits a cache your own process just wrote and reads
-    straight back, where damage would mean a bug or a hardware fault rather than adversarial input.
-
-`none`
-:   Checks nothing. Reading a damaged image is undefined behavior, so use it only for an image you trust as much as
-    your own memory.
-
-**Lifetime.** Overloads 1 and 2 borrow `image`: it must stay alive and byte-for-byte unchanged for as long as the
-returned document, and any [view](../basic_json_view/index.md) taken from it, is used -- exactly like a document
-[`parse()`](parse.md) borrowed its input for. Overload 3 avoids this by keeping the vector itself; see
-[`owns_source`](owns_source.md).
-
-!!! warning "Experimental"
-
-    The image format is versioned but not yet stable, and may change in an incompatible way before it is declared
-    stable; `load()` already rejects an image written by a different format version with `parse_error.116`
-    ("unknown format"). Use images to cache a document within one build of the library, or to hand one to another
-    process running the *same* build on the *same* (little-endian) machine -- not as a long-term storage format.
-
-## Examples
-
-??? example "Caching a document, ownership, and a rejected image"
-
-    The example below saves a parsed document as an image, checks that `load()` reproduces the original
-    [`dump()`](../basic_json_view/dump.md) without parsing, and shows the difference between
-    `load(std::move(image))` (owned) and `load(image)` (borrowed). It then damages one byte of the image and shows
-    `image_check::full` rejecting it with `parse_error.116`, while `image_check::bounds` -- meant for a cache the
-    process already trusts -- still reads it without going out of bounds.
-
-    ```cpp
-    --8<-- "examples/basic_json_document__load.cpp"
-    ```
-
-    Output:
-
-    ```json
-    --8<-- "examples/basic_json_document__load.output"
-    ```
-
-## See also
-
- [save](save.md) - write the document as an image
- [owns_source](owns_source.md) - return whether the document holds its own copy of the text
- [parse](parse.md) - deserialize from JSON text instead of an image
- [Images](../../features/json_view.md#images) - why and when to use images
-
-## Version history
-
- Added in version 3.13.0.
@@ -149,7 +149,6 @@ buffer of a given length, pass a pair of pointers: `#!cpp parse(ptr, ptr + len)`
 - [accept](accept.md) - check whether the input is valid JSON
 - [read](read.md) - (re-)parse into this document, reusing its memory
 - [owns_source](owns_source.md) - return whether the document holds its own copy of the text
- [load](load.md) - read a document from an image instead of parsing JSON text
 - [`BasicJsonType::parse`](../basic_json/parse.md) - the corresponding function of `basic_json`

 ## Version history
@@ -80,7 +80,6 @@ compile; see [`parse`](parse.md#notes).

 - [parse](parse.md) - deserialize from a compatible input
 - [root](root.md) - the view of the root value
- [load](load.md) - read a document from an image instead of parsing JSON text

 ## Version history

@@ -1,104 +0,0 @@
-# <small>nlohmann::basic_json_document::</small>save
-
-```cpp
-std::vector<std::uint8_t> save() const;
-```
-
-Writes the document as an *image*: a byte buffer that [`load`](load.md) reads back without parsing. The image holds
-the node index, the source text (plus, for an edited document, the number tokens edits wrote), and the decoded
-strings (plus the strings edits wrote) -- everything [`root()`](root.md) needs, with nothing left to parse.
-
-An edited document is written in its *current* state, with its values in document order, the way the library's own
-parser would have produced them for that JSON text: a member [`set`](set.md) added goes at the end, an
-[`erase`](erase.md)d member leaves no trace, and a float that is not finite (NaN or positive/negative infinity)
-becomes null, the same substitution [`dump()`](../basic_json_view/dump.md) makes. The same document always saves to
-the same bytes -- also across `BasicJsonType` and `#!cpp Editable`, since the image reflects document order and
-values only, not which specialization produced them.
-
-## Return value
-
-The image, as a `#!cpp std::vector<std::uint8_t>`. Pass it, or a pointer to its data together with its size, to
-[`load`](load.md) to read the document back.
-
-## Exception safety
-
-Strong guarantee: `save()` does not modify `#!cpp *this` (it is `#!cpp const`), so if it throws, the document is left
-exactly as it was, and the partially built image is discarded with the exception.
-
-## Exceptions
-
-Throws [`type_error.320`](../../home/exceptions.md#jsonexceptiontype_error320) if the document is
-[discarded](is_discarded.md) -- a default-constructed document, or one a failed [`parse()`](parse.md)/
-[`read()`](read.md) with `allow_exceptions == false` left discarded.
-
-On a big-endian target, throws `type_error.320` with a different message instead: the image format is little-endian
-only (see [Notes](#notes)).
-
-Throws [`out_of_range.416`](../../home/exceptions.md#jsonexceptionout_of_range416) if the node count, the text, or
-the decoded strings of the image would individually reach 4 GiB -- the same 32-bit offsets
-[`parse()`](parse.md#exceptions) and, for edits, [`set`](set.md)/[`push_back`](push_back.md) are already limited to.
-
-!!! failure "Example messages"
-
-    ```
-    [json.exception.type_error.320] cannot save a discarded json_document
-    ```
-    ```
-    [json.exception.type_error.320] json_document images need a little-endian target
-    ```
-    ```
-    [json.exception.out_of_range.416] images of 4 GiB or more are not supported by json_document
-    ```
-
-## Complexity
-
-Linear in the size of the document: the number of nodes, plus the length of the text and the decoded strings that end
-up in the image.
-
-## Notes
-
-**Format.** The image begins with a 64-byte header (the magic bytes `#!cpp "NJVI"`, a version number, the node count,
-and the sizes of the text and the decoded strings, all little-endian), followed by the nodes
-([16 bytes each](../../home/architecture.md#node-index-of-json-views)), the text and a `#!cpp '\0'`, and the decoded
-strings and a `#!cpp '\0'`. [`load`](load.md) checks the header, and the sizes it describes, before reading anything
-else -- see [`load`'s Exceptions](load.md#exceptions).
-
-!!! warning "Experimental"
-
-    The image format is versioned but not yet stable: it may change in an incompatible way before it is declared
-    stable. Use images to cache a document within one build of the library, or to hand one to another process running
-    the *same* build on the *same* (little-endian) machine -- not as a long-term storage format. Keep the original
-    JSON text if you need to read a saved document back with a future library version.
-
-**Little-endian only.** The image is written as raw little-endian bytes, with no byte-swapping. `save()` (and
-[`load`](load.md)) throw `type_error.320` on a big-endian target rather than silently produce bytes a big-endian
-reader could not interpret correctly.
-
-## Examples
-
-??? example "Caching a parsed document as an image"
-
-    The example below saves a parsed configuration as an image -- the way a service might cache one to answer later
-    requests without parsing the text again -- and confirms that loading it back gives exactly the same result as
-    parsing did, and that saving is deterministic.
-
-    ```cpp
-    --8<-- "examples/basic_json_document__save.cpp"
-    ```
-
-    Output:
-
-    ```json
-    --8<-- "examples/basic_json_document__save.output"
-    ```
-
-## See also
-
- [load](load.md) - read an image written by `save()`
- [owns_source](owns_source.md) - return whether the document holds its own copy of the text
- [`basic_json_view::dump`](../basic_json_view/dump.md) - serialize the document to JSON text instead of an image
- [Images](../../features/json_view.md#images) - why and when to use images
-
-## Version history
-
- Added in version 3.13.0.
@@ -1,32 +0,0 @@
-# <small>nlohmann::byte_container_with_subtype::</small>container_type
-
-```cpp
-using container_type = BinaryType;
-```
-
-The type of the underlying binary container, forwarded from the `BinaryType` template parameter that
-`byte_container_with_subtype` is instantiated with. `byte_container_with_subtype` publicly inherits from
-`container_type`.
-
-See [`basic_json::binary_t`](../basic_json/binary_t.md) for the type typically used to instantiate
-`BinaryType`.
-
-## Examples
-
-??? example
-
-    The example shows the type `container_type`.
-
-    ```cpp
-    --8<-- "examples/byte_container_with_subtype__container_type.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/byte_container_with_subtype__container_type.output"
-    ```
-
-## Version history
-
- Since version 3.8.0.
@@ -1,28 +0,0 @@
-# <small>nlohmann::byte_container_with_subtype::</small>subtype_type
-
-```cpp
-using subtype_type = std::uint64_t;
-```
-
-The type used to store the optional binary subtype tag. See [`subtype`](subtype.md) and
-[`set_subtype`](set_subtype.md).
-
-## Examples
-
-??? example
-
-    The example shows the type `subtype_type`.
-
-    ```cpp
-    --8<-- "examples/byte_container_with_subtype__subtype_type.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/byte_container_with_subtype__subtype_type.output"
-    ```
-
-## Version history
-
- Since version 3.8.0.
@@ -1,30 +0,0 @@
-# <small>nlohmann::json_sax::</small>binary_t
-
-```cpp
-using binary_t = typename BasicJsonType::binary_t;
-```
-
-The type used by the [`binary`](binary.md) callback for JSON binary values, forwarded from the
-`BasicJsonType` template parameter.
-
-See [`basic_json::binary_t`](../basic_json/binary_t.md) for more information.
-
-## Examples
-
-??? example
-
-    The example shows the type `binary_t` and its relation to `basic_json::binary_t`.
-
-    ```cpp
-    --8<-- "examples/json_sax__binary_t.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/json_sax__binary_t.output"
-    ```
-
-## Version history
-
- Added in version 3.8.0.
@@ -1,33 +0,0 @@
-# <small>nlohmann::json_sax::</small>json_sax
-
-```cpp
-// (1)
-json_sax() = default;
-
-// (2)
-json_sax(const json_sax&) = default;
-
-// (3)
-json_sax(json_sax&&) noexcept = default;
-```
-
-1. Default constructor.
-2. Copy constructor.
-3. Move constructor.
-
-`json_sax` is a pure abstract base class with no data members of its own, so all three constructors are
-defaulted and only exist to make derived SAX consumers explicitly copyable/movable.
-
-## Exception safety
-
-No-throw guarantee: none of these constructors throw exceptions.
-
-## Complexity
-
-Constant.
-
-<!-- NOLINT Examples -->
-
-## Version history
-
- Added in version 3.2.0.
@@ -1,30 +0,0 @@
-# <small>nlohmann::json_sax::</small>number_float_t
-
-```cpp
-using number_float_t = typename BasicJsonType::number_float_t;
-```
-
-The type used by the [`number_float`](number_float.md) callback for JSON floating-point numbers,
-forwarded from the `BasicJsonType` template parameter.
-
-See [`basic_json::number_float_t`](../basic_json/number_float_t.md) for more information.
-
-## Examples
-
-??? example
-
-    The example shows the type `number_float_t` and its relation to `basic_json::number_float_t`.
-
-    ```cpp
-    --8<-- "examples/json_sax__number_float_t.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/json_sax__number_float_t.output"
-    ```
-
-## Version history
-
- Added in version 3.2.0.
@@ -1,30 +0,0 @@
-# <small>nlohmann::json_sax::</small>number_integer_t
-
-```cpp
-using number_integer_t = typename BasicJsonType::number_integer_t;
-```
-
-The type used by the [`number_integer`](number_integer.md) callback for JSON integer numbers, forwarded
-from the `BasicJsonType` template parameter.
-
-See [`basic_json::number_integer_t`](../basic_json/number_integer_t.md) for more information.
-
-## Examples
-
-??? example
-
-    The example shows the type `number_integer_t` and its relation to `basic_json::number_integer_t`.
-
-    ```cpp
-    --8<-- "examples/json_sax__number_integer_t.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/json_sax__number_integer_t.output"
-    ```
-
-## Version history
-
- Added in version 3.2.0.
@@ -1,30 +0,0 @@
-# <small>nlohmann::json_sax::</small>number_unsigned_t
-
-```cpp
-using number_unsigned_t = typename BasicJsonType::number_unsigned_t;
-```
-
-The type used by the [`number_unsigned`](number_unsigned.md) callback for JSON unsigned integer numbers,
-forwarded from the `BasicJsonType` template parameter.
-
-See [`basic_json::number_unsigned_t`](../basic_json/number_unsigned_t.md) for more information.
-
-## Examples
-
-??? example
-
-    The example shows the type `number_unsigned_t` and its relation to `basic_json::number_unsigned_t`.
-
-    ```cpp
-    --8<-- "examples/json_sax__number_unsigned_t.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/json_sax__number_unsigned_t.output"
-    ```
-
-## Version history
-
- Added in version 3.2.0.
@@ -1,29 +0,0 @@
-# <small>nlohmann::json_sax::</small>operator=
-
-```cpp
-// (1)
-json_sax& operator=(const json_sax&) = default;
-
-// (2)
-json_sax& operator=(json_sax&&) noexcept = default;
-```
-
-1. Copy assignment operator.
-2. Move assignment operator.
-
-`json_sax` is a pure abstract base class with no data members of its own, so both assignment operators
-are defaulted and only exist to make derived SAX consumers explicitly copy-/move-assignable.
-
-## Exception safety
-
-No-throw guarantee: neither operator throws exceptions.
-
-## Complexity
-
-Constant.
-
-<!-- NOLINT Examples -->
-
-## Version history
-
- Added in version 3.2.0.
@@ -1,30 +0,0 @@
-# <small>nlohmann::json_sax::</small>string_t
-
-```cpp
-using string_t = typename BasicJsonType::string_t;
-```
-
-The type used by the [`string`](string.md) and [`key`](key.md) callbacks for JSON strings and object
-keys, forwarded from the `BasicJsonType` template parameter.
-
-See [`basic_json::string_t`](../basic_json/string_t.md) for more information.
-
-## Examples
-
-??? example
-
-    The example shows the type `string_t` and its relation to `basic_json::string_t`.
-
-    ```cpp
-    --8<-- "examples/json_sax__string_t.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/json_sax__string_t.output"
-    ```
-
-## Version history
-
- Added in version 3.2.0.
@@ -1,22 +0,0 @@
-# <small>nlohmann::json_sax::</small>~json_sax
-
-```cpp
-virtual ~json_sax() = default;
-```
-
-Destructor. Virtual to allow proper destruction of derived SAX consumer classes through a
-pointer/reference to `json_sax`.
-
-## Exception safety
-
-No-throw guarantee: this destructor never throws exceptions.
-
-## Complexity
-
-Constant.
-
-<!-- NOLINT Examples -->
-
-## Version history
-
- Added in version 3.2.0.
@@ -10,9 +10,6 @@ earlier, instead of locking the file once and reading it with the unlocked stdio
 It does not change any result: values, exceptions, and the position of the file after parsing are the same either way.
 Only the speed and the locking of the file differ (see the notes on locking below).

-Builds with MemorySanitizer use `std::fgetc` automatically, because the inline `getc_unlocked` of glibc reads the stdio
-buffer directly, which glibc (not instrumented) filled, and MemorySanitizer would report it as uninitialized.
-
 ## Default definition

 The default value is `0`: the file is locked once and read with the unlocked stdio functions where they are available.
@@ -8,16 +8,16 @@ This type preserves the insertion order of object keys.

 ## Iterator invalidation

-The type is based on [`ordered_map`](ordered_map/index.md) which in turn uses a `std::vector` to store object elements.
+The type is based on [`ordered_map`](ordered_map.md) which in turn uses a `std::vector` to store object elements.
 Therefore, adding object elements can yield a reallocation in which case all iterators (including the
 [`end()`](basic_json/end.md) iterator) and all references to the elements are invalidated. Also, any iterator or
 reference after the insertion point will point to the same index, which is now a different value.

 ## Complexity

-[`ordered_map`](ordered_map/index.md) has no lookup index: every key-based object operation is a linear scan, so building or
+[`ordered_map`](ordered_map.md) has no lookup index: every key-based object operation is a linear scan, so building or
 parsing an object of `n` keys costs O(n²) rather than O(n log n). See
-[`ordered_map` complexity](ordered_map/index.md#complexity) for the per-operation table and for measured numbers.
+[`ordered_map` complexity](ordered_map.md#complexity) for the per-operation table and for measured numbers.

 ## Examples

@@ -37,7 +37,7 @@ parsing an object of `n` keys costs O(n²) rather than O(n log n). See

 ## See also

- [ordered_map](ordered_map/index.md)
+- [ordered_map](ordered_map.md)
 - [Object Order](../features/object_order.md)

 ## Version history
@@ -6,7 +6,7 @@ template<class Key, class T, class IgnoredLess = std::less<Key>,
 struct ordered_map : std::vector<std::pair<const Key, T>, Allocator>;
 ```

-A minimal map-like container that preserves insertion order for use within [`nlohmann::ordered_json`](../ordered_json.md)
+A minimal map-like container that preserves insertion order for use within [`nlohmann::ordered_json`](ordered_json.md)
 (`nlohmann::basic_json<ordered_map>`).

 ## Template parameters
@@ -30,19 +30,19 @@ case all iterators (including the `end()` iterator) and all references to the el

 When the storage grows, the keys are copied and the mapped values are moved to the new storage. A plain `std::vector`
 would copy the whole elements instead, because their `#!cpp const` keys make them not nothrow move constructible; for
-[`ordered_json`](../ordered_json.md), this would be a deep copy of every nested value. The values are only copied if
+[`ordered_json`](ordered_json.md), this would be a deep copy of every nested value. The values are only copied if
 `T` is not default constructible or not nothrow move assignable.

 ## Member types

 - **key_type** - key type (`Key`)
 - **mapped_type** - mapped type (`T`)
- [**Container**](Container.md) - base container type (`#!cpp std::vector<std::pair<const Key, T>, Allocator>`)
+- **Container** - base container type (`#!cpp std::vector<std::pair<const Key, T>, Allocator>`)
 - **iterator**
 - **const_iterator**
 - **size_type**
 - **value_type**
- [**key_compare**](key_compare.md) - key comparison function
+- **key_compare** - key comparison function
 ```cpp
 std::equal_to<Key>  // until C++14

@@ -51,16 +51,15 @@ std::equal_to<>     // since C++14

 ## Member functions

- [(constructor)](ordered_map.md)
- [(destructor)](~ordered_map.md)
- [**operator=**](operator=.md)
- [**emplace**](emplace.md)
- [**operator\[\]**](operator[].md)
- [**at**](at.md)
- [**erase**](erase.md)
- [**count**](count.md)
- [**find**](find.md)
- [**insert**](insert.md)
+- (constructor)
+- (destructor)
+- **emplace**
+- **operator\[\]**
+- **at**
+- **erase**
+- **count**
+- **find**
+- **insert**

 ## Exception safety

@@ -90,7 +89,7 @@ This differs from `#!cpp std::map`, where the same operations are O(log n).
 !!! warning "Quadratic cost of building large objects"

    Because every insertion scans all elements inserted so far, building an object of `n` distinct keys costs
-    **O(n²)** in total. This applies to filling an [`ordered_json`](../ordered_json.md) object key by key as well as to
+    **O(n²)** in total. This applies to filling an [`ordered_json`](ordered_json.md) object key by key as well as to
    parsing one, since the parser inserts each key as it is read.

    The cost is negligible for the object sizes typically found in configuration files or API payloads, but it grows
@@ -107,7 +106,7 @@ This differs from `#!cpp std::map`, where the same operations are O(log n).
    If key order matters for objects of that size, consider a container with a lookup index, such as
    [`nlohmann::fifo_map`](https://github.com/nlohmann/fifo_map)
    ([integration](https://github.com/nlohmann/json/issues/485#issuecomment-333652309)), as the object type -- see
-    [object order](../../features/object_order.md).
+    [object order](../features/object_order.md).

 ## Examples

@@ -127,10 +126,10 @@ This differs from `#!cpp std::map`, where the same operations are O(log n).

 ## See also

- [ordered_json](../ordered_json.md)
+- [ordered_json](ordered_json.md)

 ## Version history

- Added in version 3.9.0 to implement [`nlohmann::ordered_json`](../ordered_json.md).
+- Added in version 3.9.0 to implement [`nlohmann::ordered_json`](ordered_json.md).
 - Added **key_compare** member in version 3.11.0.
 - Changed in version 3.13.0: growing the storage moves the mapped values instead of copying them.
@@ -1,28 +0,0 @@
-# <small>nlohmann::ordered_map::</small>Container
-
-```cpp
-using Container = std::vector<std::pair<const Key, T>, Allocator>;
-```
-
-The base container type that `ordered_map` publicly inherits from. Elements are stored in insertion
-order as `#!cpp std::pair<const Key, T>` entries in a `std::vector`.
-
-## Examples
-
-??? example
-
-    The example shows the type `Container`.
-
-    ```cpp
-    --8<-- "examples/ordered_map__Container.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/ordered_map__Container.output"
-    ```
-
-## Version history
-
- Added in version 3.9.0 to implement [`nlohmann::ordered_json`](../ordered_json.md).
@@ -1,61 +0,0 @@
-# <small>nlohmann::ordered_map::</small>at
-
-```cpp
-// (1)
-T& at(const key_type& key);
-const T& at(const key_type& key) const;
-
-// (2)
-template<class KeyType>
-T& at(KeyType&& key);
-template<class KeyType>
-const T& at(KeyType&& key) const;
-```
-
-1. Returns a reference to the value mapped to `key`.
-2. Same as (1), but for any `KeyType` comparable to `key_type` via [`key_compare`](key_compare.md)
-   (heterogeneous lookup, e.g. looking up by a `#!cpp const char*` without constructing a temporary
-   `key_type`). Only participates in overload resolution if `KeyType` is usable as a key type.
-
-## Template parameters
-
-`KeyType`
-:   a type comparable to `key_type` via [`key_compare`](key_compare.md)
-
-## Parameters
-
-`key` (in)
-:   key of the element to find
-
-## Return value
-
-reference to the mapped value of the element with key equal to `key`
-
-## Exceptions
-
-Throws `std::out_of_range` if no element with key `key` exists.
-
-## Complexity
-
-Linear in the number of elements.
-
-## Examples
-
-??? example
-
-    The example shows how `at` is used.
-
-    ```cpp
-    --8<-- "examples/ordered_map__at.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/ordered_map__at.output"
-    ```
-
-## Version history
-
- Added in version 3.9.1 to implement [`nlohmann::ordered_json`](../ordered_json.md).
- Overload (2) added in version 3.11.0.
@@ -1,53 +0,0 @@
-# <small>nlohmann::ordered_map::</small>count
-
-```cpp
-// (1)
-size_type count(const key_type& key) const;
-
-// (2)
-template<class KeyType>
-size_type count(KeyType&& key) const;
-```
-
-1. Returns the number of elements with key equal to `key` (0 or 1, since keys are unique).
-2. Same as (1), but for any `KeyType` comparable to `key_type` via [`key_compare`](key_compare.md)
-   (heterogeneous lookup). Only participates in overload resolution if `KeyType` is usable as a key type.
-
-## Template parameters
-
-`KeyType`
-:   a type comparable to `key_type` via [`key_compare`](key_compare.md)
-
-## Parameters
-
-`key` (in)
-:   key of the elements to count
-
-## Return value
-
-number of elements with key equal to `key` (0 or 1)
-
-## Complexity
-
-Linear in the number of elements.
-
-## Examples
-
-??? example
-
-    The example shows how `count` is used.
-
-    ```cpp
-    --8<-- "examples/ordered_map__count.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/ordered_map__count.output"
-    ```
-
-## Version history
-
- Added in version 3.9.1 to implement [`nlohmann::ordered_json`](../ordered_json.md).
- Overload (2) added in version 3.11.0.
@@ -1,58 +0,0 @@
-# <small>nlohmann::ordered_map::</small>emplace
-
-```cpp
-// (1)
-std::pair<iterator, bool> emplace(const key_type& key, T&& t);
-
-// (2)
-template<class KeyType>
-std::pair<iterator, bool> emplace(KeyType&& key, T&& t);
-```
-
-1. Inserts `#!cpp {key, t}` if no element with an equal key already exists (per [`key_compare`](key_compare.md)),
-   appending it at the end to preserve insertion order. If an equal key already exists, does nothing.
-2. Same as (1), but for any `KeyType` comparable to `key_type` via [`key_compare`](key_compare.md)
-   (heterogeneous lookup). Only participates in overload resolution if `KeyType` is usable as a key type.
-
-## Template parameters
-
-`KeyType`
-:   a type comparable to `key_type` via [`key_compare`](key_compare.md)
-
-## Parameters
-
-`key` (in)
-:   key of the element to insert
-
-`t` (in)
-:   value of the element to insert
-
-## Return value
-
-pair of an iterator to the (possibly newly inserted) element, and a `bool` that is `true` if insertion
-took place and `false` if an element with an equal key already existed
-
-## Complexity
-
-Linear in the number of elements.
-
-## Examples
-
-??? example
-
-    The example shows how `emplace` is used.
-
-    ```cpp
-    --8<-- "examples/ordered_map__emplace.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/ordered_map__emplace.output"
-    ```
-
-## Version history
-
- Added in version 3.9.0 to implement [`nlohmann::ordered_json`](../ordered_json.md).
- Overload (2) added in version 3.11.0.
@@ -1,75 +0,0 @@
-# <small>nlohmann::ordered_map::</small>erase
-
-```cpp
-// (1)
-size_type erase(const key_type& key);
-
-// (2)
-template<class KeyType>
-size_type erase(KeyType&& key);
-
-// (3)
-iterator erase(iterator pos);
-
-// (4)
-iterator erase(iterator first, iterator last);
-```
-
-1. Removes the element with key equal to `key`, if any, preserving the relative order of the remaining
-   elements.
-2. Same as (1), but for any `KeyType` comparable to `key_type` via [`key_compare`](key_compare.md)
-   (heterogeneous lookup). Only participates in overload resolution if `KeyType` is usable as a key type.
-3. Removes the element at `pos`.
-4. Removes the elements in range `[first, last)`.
-
-## Template parameters
-
-`KeyType`
-:   a type comparable to `key_type` via [`key_compare`](key_compare.md)
-
-## Parameters
-
-`key` (in)
-:   key of the element to remove
-
-`pos` (in)
-:   iterator to the element to remove
-
-`first` (in)
-:   iterator to the first element to remove
-
-`last` (in)
-:   iterator one past the last element to remove
-
-## Return value
-
-1. number of elements removed (0 or 1)
-2. number of elements removed (0 or 1)
-3. iterator following the removed element
-4. iterator following the last removed element
-
-## Complexity
-
-Linear in the number of elements (elements after the removed one(s) are shifted to keep storage
-contiguous).
-
-## Examples
-
-??? example
-
-    The example shows how `erase` is used.
-
-    ```cpp
-    --8<-- "examples/ordered_map__erase.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/ordered_map__erase.output"
-    ```
-
-## Version history
-
- Added in version 3.9.0 to implement [`nlohmann::ordered_json`](../ordered_json.md).
- Overload (2) added in version 3.11.0.
@@ -1,56 +0,0 @@
-# <small>nlohmann::ordered_map::</small>find
-
-```cpp
-// (1)
-iterator find(const key_type& key);
-const_iterator find(const key_type& key) const;
-
-// (2)
-template<class KeyType>
-iterator find(KeyType&& key);
-template<class KeyType>
-const_iterator find(KeyType&& key) const;
-```
-
-1. Returns an iterator to the element with key equal to `key`, or `end()` if no such element exists.
-2. Same as (1), but for any `KeyType` comparable to `key_type` via [`key_compare`](key_compare.md)
-   (heterogeneous lookup). Only participates in overload resolution if `KeyType` is usable as a key type.
-
-## Template parameters
-
-`KeyType`
-:   a type comparable to `key_type` via [`key_compare`](key_compare.md)
-
-## Parameters
-
-`key` (in)
-:   key of the element to find
-
-## Return value
-
-iterator to the element with key equal to `key`, or `end()` if not found
-
-## Complexity
-
-Linear in the number of elements.
-
-## Examples
-
-??? example
-
-    The example shows how `find` is used.
-
-    ```cpp
-    --8<-- "examples/ordered_map__find.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/ordered_map__find.output"
-    ```
-
-## Version history
-
- Added in version 3.9.1 to implement [`nlohmann::ordered_json`](../ordered_json.md).
- Overload (2) added in version 3.11.0.
@@ -1,63 +0,0 @@
-# <small>nlohmann::ordered_map::</small>insert
-
-```cpp
-// (1)
-std::pair<iterator, bool> insert(value_type&& value);
-std::pair<iterator, bool> insert(const value_type& value);
-
-// (2)
-template<typename InputIt>
-void insert(InputIt first, InputIt last);
-```
-
-1. Inserts `value` if no element with an equal key already exists (per [`key_compare`](key_compare.md)),
-   appending it at the end to preserve insertion order. If an equal key already exists, does nothing.
-2. Inserts the elements from range `[first, last)`, in iteration order, applying the same equal-key rule
-   as (1) to each element.
-
-## Template parameters
-
-`InputIt`
-:   an input iterator type
-
-## Parameters
-
-`value` (in)
-:   value to insert
-
-`first` (in)
-:   iterator to the first element to insert
-
-`last` (in)
-:   iterator one past the last element to insert
-
-## Return value
-
-1. pair of an iterator to the (possibly newly inserted) element, and a `bool` that is `true` if insertion
-   took place and `false` if an element with an equal key already existed
-2. (none)
-
-## Complexity
-
-1. Linear in the number of elements.
-2. Linear in the distance between `first` and `last`, times linear in the number of elements.
-
-## Examples
-
-??? example
-
-    The example shows how `insert` is used.
-
-    ```cpp
-    --8<-- "examples/ordered_map__insert.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/ordered_map__insert.output"
-    ```
-
-## Version history
-
- Added in version 3.9.1 to implement [`nlohmann::ordered_json`](../ordered_json.md).
@@ -1,34 +0,0 @@
-# <small>nlohmann::ordered_map::</small>key_compare
-
-```cpp
-using key_compare = std::equal_to<Key>;  // until C++14
-
-using key_compare = std::equal_to<>;     // since C++14
-```
-
-The comparator used to determine key equality when looking up elements. Unlike `std::map`, `ordered_map`
-uses linear search with `key_compare` rather than an ordering relation, since element order reflects
-insertion order rather than key order.
-
-Since C++14, the transparent `#!cpp std::equal_to<>` is used, which enables heterogeneous lookup (e.g.
-looking up by a `#!cpp const char*` key without constructing a temporary `Key`).
-
-## Examples
-
-??? example
-
-    The example shows how `key_compare` is used.
-
-    ```cpp
-    --8<-- "examples/ordered_map__key_compare.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/ordered_map__key_compare.output"
-    ```
-
-## Version history
-
- Added in version 3.11.0.
@@ -1,32 +0,0 @@
-# <small>nlohmann::ordered_map::</small>operator=
-
-```cpp
-// (1)
-ordered_map& operator=(const ordered_map& other);
-
-// (2)
-ordered_map& operator=(ordered_map&& other) noexcept(std::is_nothrow_move_assignable<Container>::value);
-```
-
-1. Copy assignment operator.
-2. Move assignment operator.
-
-## Parameters
-
-`other` (in)
-:   value to assign from
-
-## Return value
-
-`*this`
-
-## Complexity
-
-1. Linear in the size of `other`.
-2. Constant.
-
-<!-- NOLINT Examples -->
-
-## Version history
-
- Added in version 3.9.0 to implement [`nlohmann::ordered_json`](../ordered_json.md).
@@ -1,62 +0,0 @@
-# <small>nlohmann::ordered_map::</small>operator[]
-
-```cpp
-// (1)
-T& operator[](const key_type& key);
-const T& operator[](const key_type& key) const;
-
-// (2)
-template<class KeyType>
-T& operator[](KeyType&& key);
-template<class KeyType>
-const T& operator[](KeyType&& key) const;
-```
-
-1. Returns a reference to the value mapped to `key`, inserting a default-constructed `T` (non-`const`
-   overload only) if no such element exists yet.
-2. Same as (1), but for any `KeyType` comparable to `key_type` via [`key_compare`](key_compare.md)
-   (heterogeneous lookup). Only participates in overload resolution if `KeyType` is usable as a key type.
-
-## Template parameters
-
-`KeyType`
-:   a type comparable to `key_type` via [`key_compare`](key_compare.md)
-
-## Parameters
-
-`key` (in)
-:   key of the element to find or insert
-
-## Return value
-
-reference to the mapped value of the element with key equal to `key`
-
-## Exceptions
-
-The `const` overloads throw `std::out_of_range` if no element with key `key` exists (they delegate to
-[`at`](at.md)).
-
-## Complexity
-
-Linear in the number of elements.
-
-## Examples
-
-??? example
-
-    The example shows how `operator[]` is used.
-
-    ```cpp
-    --8<-- "examples/ordered_map__operator_idx.cpp"
-    ```
-
-    Output:
-
-    ```
-    --8<-- "examples/ordered_map__operator_idx.output"
-    ```
-
-## Version history
-
- Added in version 3.9.0 to implement [`nlohmann::ordered_json`](../ordered_json.md).
- Overload (2) added in version 3.11.0.
@@ -1,66 +0,0 @@
-# <small>nlohmann::ordered_map::</small>ordered_map
-
-```cpp
-// (1)
-ordered_map() noexcept(noexcept(Container()));
-
-// (2)
-explicit ordered_map(const Allocator& alloc) noexcept(noexcept(Container(alloc)));
-
-// (3)
-template <class It>
-ordered_map(It first, It last, const Allocator& alloc = Allocator());
-
-// (4)
-ordered_map(std::initializer_list<value_type> init, const Allocator& alloc = Allocator());
-
-// (5)
-ordered_map(const ordered_map&) = default;
-
-// (6)
-ordered_map(ordered_map&&) noexcept(std::is_nothrow_move_constructible<Container>::value) = default;
-```
-
-1. Default constructor. Creates an empty `ordered_map`.
-2. Creates an empty `ordered_map` using the given allocator.
-3. Creates an `ordered_map` from the elements in range `[first, last)`, inserted in iteration order.
-4. Creates an `ordered_map` from an initializer list of key/value pairs, inserted in list order.
-5. Copy constructor.
-6. Move constructor.
-
-These constructors are declared explicitly (rather than inherited via `#!cpp using Container::Container`)
-because older compilers (GCC <= 5.5, Xcode <= 9.4) do not handle the inherited constructors correctly.
-
-## Template parameters
-
-`It`
-:   an input iterator type
-
-## Parameters
-
-`alloc` (in)
-:   allocator to use for the underlying container
-
-`first` (in)
-:   iterator to the first element to insert
-
-`last` (in)
-:   iterator one past the last element to insert
-
-`init` (in)
-:   initializer list of key/value pairs to insert
-
-## Complexity
-
-1. Constant.
-2. Constant.
-3. Linear in the distance between `first` and `last`.
-4. Linear in the size of `init`.
-5. Linear in the size of `other`.
-6. Constant.
-
-<!-- NOLINT Examples -->
-
-## Version history
-
- Added in version 3.9.0 to implement [`nlohmann::ordered_json`](../ordered_json.md).
@@ -1,17 +0,0 @@
-# <small>nlohmann::ordered_map::</small>~ordered_map
-
-```cpp
-~ordered_map() = default;
-```
-
-Destroys the `ordered_map` and frees all allocated memory.
-
-## Complexity
-
-Linear in the number of elements.
-
-<!-- NOLINT Examples -->
-
-## Version history
-
- Added in version 3.9.0 to implement [`nlohmann::ordered_json`](../ordered_json.md).
@@ -1,52 +0,0 @@
-#include <cstdint>
-#include <iostream>
-#include <string>
-#include <vector>
-#include <nlohmann/json_view.hpp>
-
-using json = nlohmann::json;
-using json_document = nlohmann::json_document;
-using image_check = json_document::image_check;
-
-int main()
-{
-    std::cout << std::boolalpha;
-
-    // the image of a parsed document -- as if read back from a cache file or
-    // received from another process running the same build of the library
-    const std::string text = R"({"name": "cache", "note": "caf\u00e9", "replicas": ["db2", "db3"]})";
-    const json_document parsed = json_document::parse(text);
-    const std::vector<std::uint8_t> image = parsed.save();
-
-    // (1)/(2) load() needs no parsing, yet dumps exactly what parsing did
-    const json_document borrowed = json_document::load(image);
-    std::cout << (borrowed.root().dump() == parsed.root().dump()) << '\n';
-    std::cout << borrowed.owns_source() << '\n'; // borrowed: still points into `image`
-
-    // (3) load(std::move(image)) keeps the vector instead of copying it
-    std::vector<std::uint8_t> to_move = image;
-    const json_document owned = json_document::load(std::move(to_move));
-    std::cout << owned.owns_source() << '\n';
-
-    // a damaged image -- the last byte of the decoded string "note" holds
-    // (an escape sequence, so it was unescaped into the document's own
-    // buffer), flipped, as storage or transport corruption might do
-    std::vector<std::uint8_t> damaged = image;
-    damaged[damaged.size() - 2] = 0xFF;
-
-    // image_check::full inspects strings and numbers, so it catches the damage
-    try
-    {
-        static_cast<void>(json_document::load(damaged, image_check::full));
-    }
-    catch (const json::parse_error& e)
-    {
-        std::cout << e.id << '\n';
-    }
-
-    // image_check::bounds only checks structure and bounds, so a cache the
-    // process already trusts loads without the extra scan -- reading a value
-    // the damage did not touch is still safe
-    const json_document trusted = json_document::load(damaged, image_check::bounds);
-    std::cout << trusted.root()["name"].get<std::string>() << '\n';
-}
@@ -1,5 +0,0 @@
-true
-false
-true
-116
-cache
@@ -1,30 +0,0 @@
-#include <cstdint>
-#include <iostream>
-#include <string>
-#include <vector>
-#include <nlohmann/json_view.hpp>
-
-using json_document = nlohmann::json_document;
-
-int main()
-{
-    std::cout << std::boolalpha;
-
-    // a configuration a service parses once and then caches as an image, so
-    // that later requests can load() it instead of parsing the text again
-    const std::string text = R"({"name": "cache", "host": "db1", "port": 6379, "replicas": ["db2", "db3"]})";
-    const json_document config = json_document::parse(text);
-
-    // save() turns the parsed document into a byte buffer: a 64-byte header,
-    // the node index, the source text, and the decoded strings
-    const std::vector<std::uint8_t> image = config.save();
-    std::cout << image.size() << '\n';
-
-    // the same document always saves to the same bytes
-    std::cout << (image == json_document::parse(text).save()) << '\n';
-
-    // loading the image back needs no parsing, yet dumps exactly what
-    // parsing the text produced
-    const json_document reloaded = json_document::load(image);
-    std::cout << (reloaded.root().dump() == config.root().dump()) << '\n';
-}
@@ -1,3 +0,0 @@
-316
-true
-true
@@ -1,21 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-using json = nlohmann::json;
-
-int main()
-{
-    // an empty binary value is encoded differently by the two drafts:
-    // draft2 omits the optimized type marker for an empty byte array,
-    // while draft3 always writes it
-    json j = json::binary({});
-
-    // encode using BJData draft2 (the default)
-    auto v_draft2 = json::to_bjdata(j, true, true, json::bjdata_version_t::draft2);
-
-    // encode using BJData draft3
-    auto v_draft3 = json::to_bjdata(j, true, true, json::bjdata_version_t::draft3);
-
-    std::cout << "draft2 size: " << v_draft2.size() << '\n'
-              << "draft3 size: " << v_draft3.size() << std::endl;
-}
@@ -1,2 +0,0 @@
-draft2 size: 4
-draft3 size: 6
@@ -1,11 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-using byte_container_with_subtype = nlohmann::byte_container_with_subtype<std::vector<std::uint8_t>>;
-
-int main()
-{
-    std::cout << std::boolalpha
-              << std::is_same<byte_container_with_subtype::container_type, std::vector<std::uint8_t>>::value
-              << std::endl;
-}
@@ -1 +0,0 @@
-true
@@ -1,10 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-using byte_container_with_subtype = nlohmann::byte_container_with_subtype<std::vector<std::uint8_t>>;
-
-int main()
-{
-    std::cout << std::boolalpha
-              << std::is_same<byte_container_with_subtype::subtype_type, std::uint64_t>::value << std::endl;
-}
@@ -1 +0,0 @@
-true
@@ -1,13 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-using json = nlohmann::json;
-
-int main()
-{
-    // an initializer_list_t is what a braced-init-list of JSON values is deduced as
-    json::initializer_list_t init = {"a", 1, 2.0, false};
-
-    json j(init);
-    std::cout << j.dump() << std::endl;
-}
@@ -1 +0,0 @@
-["a",1,2.0,false]
@@ -1,10 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-using json = nlohmann::json;
-
-int main()
-{
-    std::cout << std::boolalpha
-              << std::is_same<json::json_sax_t::binary_t, json::binary_t>::value << std::endl;
-}
@@ -1 +0,0 @@
-true
@@ -1,10 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-using json = nlohmann::json;
-
-int main()
-{
-    std::cout << std::boolalpha
-              << std::is_same<json::json_sax_t::number_float_t, json::number_float_t>::value << std::endl;
-}
@@ -1 +0,0 @@
-true
@@ -1,10 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-using json = nlohmann::json;
-
-int main()
-{
-    std::cout << std::boolalpha
-              << std::is_same<json::json_sax_t::number_integer_t, json::number_integer_t>::value << std::endl;
-}
@@ -1 +0,0 @@
-true
@@ -1,10 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-using json = nlohmann::json;
-
-int main()
-{
-    std::cout << std::boolalpha
-              << std::is_same<json::json_sax_t::number_unsigned_t, json::number_unsigned_t>::value << std::endl;
-}
@@ -1 +0,0 @@
-true
@@ -1,10 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-using json = nlohmann::json;
-
-int main()
-{
-    std::cout << std::boolalpha
-              << std::is_same<json::json_sax_t::string_t, json::string_t>::value << std::endl;
-}
@@ -1 +0,0 @@
-true
@@ -1,10 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-using json = nlohmann::json;
-
-int main()
-{
-    std::cout << std::boolalpha
-              << std::is_same<json::json_sax_t, nlohmann::json_sax<json>>::value << std::endl;
-}
@@ -1 +0,0 @@
-true
@@ -1,12 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-int main()
-{
-    using Map = nlohmann::ordered_map<std::string, int>;
-
-    std::cout << std::boolalpha
-              << "Container is std::vector<std::pair<const Key, T>>: "
-              << std::is_same<Map::Container, std::vector<std::pair<const std::string, int>>>::value
-              << std::endl;
-}
@@ -1 +0,0 @@
-Container is std::vector<std::pair<const Key, T>>: true
@@ -1,26 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-int main()
-{
-    nlohmann::ordered_map<std::string, int> m;
-    m["one"] = 1;
-    m["two"] = 2;
-
-    // access an existing element
-    std::cout << "m.at(\"one\") = " << m.at("one") << std::endl;
-
-    // modify through the reference returned by at()
-    m.at("two") = 22;
-    std::cout << "m.at(\"two\") = " << m.at("two") << std::endl;
-
-    // accessing a missing key throws
-    try
-    {
-        m.at("three");
-    }
-    catch (const std::out_of_range& e)
-    {
-        std::cout << "exception: " << e.what() << std::endl;
-    }
-}
@@ -1,3 +0,0 @@
-m.at("one") = 1
-m.at("two") = 22
-exception: key not found
@@ -1,12 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-int main()
-{
-    nlohmann::ordered_map<std::string, int> m;
-    m["one"] = 1;
-
-    std::cout << std::boolalpha
-              << "m.count(\"one\") = " << m.count("one") << '\n'
-              << "m.count(\"two\") = " << m.count("two") << std::endl;
-}
@@ -1,2 +0,0 @@
-m.count("one") = 1
-m.count("two") = 0
@@ -1,15 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-int main()
-{
-    nlohmann::ordered_map<std::string, std::string> m;
-
-    // emplace a new element
-    auto res1 = m.emplace("one", "eins");
-    std::cout << std::boolalpha << "inserted: " << res1.second << ", value: " << res1.first->second << std::endl;
-
-    // emplace with an already-existing key: no-op, returns the existing element
-    auto res2 = m.emplace("one", "uno");
-    std::cout << std::boolalpha << "inserted: " << res2.second << ", value: " << res2.first->second << std::endl;
-}
@@ -1,2 +0,0 @@
-inserted: true, value: eins
-inserted: false, value: eins
@@ -1,24 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-int main()
-{
-    nlohmann::ordered_map<std::string, int> m;
-    m["one"] = 1;
-    m["two"] = 2;
-    m["three"] = 3;
-
-    // erase by key
-    std::size_t removed = m.erase("two");
-    std::cout << "removed by key: " << removed << std::endl;
-
-    // erase by iterator
-    m.erase(m.begin());
-
-    std::cout << "remaining: ";
-    for (const auto& element : m)
-    {
-        std::cout << element.first << ' ';
-    }
-    std::cout << std::endl;
-}
@@ -1,2 +0,0 @@
-removed by key: 1
-remaining: three 
@@ -1,19 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-int main()
-{
-    nlohmann::ordered_map<std::string, int> m;
-    m["one"] = 1;
-
-    auto it = m.find("one");
-    if (it != m.end())
-    {
-        std::cout << "found: " << it->first << " = " << it->second << std::endl;
-    }
-
-    if (m.find("two") == m.end())
-    {
-        std::cout << "\"two\" not found" << std::endl;
-    }
-}
@@ -1,2 +0,0 @@
-found: one = 1
-"two" not found
@@ -1,21 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-int main()
-{
-    nlohmann::ordered_map<std::string, int> m;
-
-    // insert a single value
-    auto res = m.insert({"one", 1});
-    std::cout << std::boolalpha << "inserted: " << res.second << std::endl;
-
-    // insert a range from another container
-    std::vector<std::pair<const std::string, int>> more = {{"two", 2}, {"three", 3}};
-    m.insert(more.begin(), more.end());
-
-    for (const auto& element : m)
-    {
-        std::cout << element.first << ':' << element.second << ' ';
-    }
-    std::cout << std::endl;
-}
@@ -1,2 +0,0 @@
-inserted: true
-one:1 two:2 three:3 
@@ -1,12 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-int main()
-{
-    using Map = nlohmann::ordered_map<std::string, int>;
-    Map::key_compare compare{};
-
-    std::cout << std::boolalpha
-              << "compare(\"a\", \"a\") = " << compare("a", "a") << '\n'
-              << "compare(\"a\", \"b\") = " << compare("a", "b") << std::endl;
-}
@@ -1,2 +0,0 @@
-compare("a", "a") = true
-compare("a", "b") = false
@@ -1,14 +0,0 @@
-#include <iostream>
-#include <nlohmann/json.hpp>
-
-int main()
-{
-    nlohmann::ordered_map<std::string, int> m;
-
-    // operator[] inserts a default-constructed value if the key doesn't exist yet
-    m["one"] = 1;
-    std::cout << "m[\"one\"] = " << m["one"] << std::endl;
-
-    // accessing again just returns the existing value
-    std::cout << "m[\"one\"] = " << m["one"] << std::endl;
-}
@@ -1,2 +0,0 @@
-m["one"] = 1
-m["one"] = 1
@@ -14,8 +14,7 @@ C++ types, and finally serialize it again.
  [parsing untrusted input](parsing/untrusted_input.md).
 - [Zero-copy JSON views](json_view.md) — read a JSON text through a flat index instead of building a `json` tree;
  strings and numbers stay in the input and are only decoded when needed.
- [Editable documents](json_view.md#editing-a-document) — modify a parsed document without building a `json` tree.
- [Images](json_view.md#images) — save a parsed document and load it again without parsing it.
+  [Editable documents](json_view.md#editing-a-document) can also be modified.
 - [Comments](comments.md) and [trailing commas](trailing_commas.md) — opt-in relaxations of the JSON grammar.

 ## Accessing and modifying values
@@ -312,57 +312,6 @@ edits. See [`basic_json_document`'s Edits](../api/basic_json_document/index.md#e
 throws (the *basic* guarantee, not the strong one `dump()` and the read-only functions provide). How edits are kept in
 the index is described in the [architecture overview](../home/architecture.md#node-index-of-json-views).

-## Images
-
-[`save()`](../api/basic_json_document/save.md) writes a document as an *image*: a byte buffer that
-[`load()`](../api/basic_json_document/load.md) reads back into a document without parsing -- no lexing, no building
-the node index, nothing but copying the nodes and pointing the text and the decoded strings at the image. Where
-[`parse_copy()`](../api/basic_json_document/parse_copy.md) still has to scan the whole input,
-[`load()`](../api/basic_json_document/load.md) turns that scan into a copy of the node index alone.
-
-**Why.** A document that is parsed once and then read many times -- a configuration loaded at startup, a template
-rendered on every request, a large reference dataset a worker process needs in memory -- pays for parsing once but
-can amortize [`save()`](../api/basic_json_document/save.md)'s cost across every later load. That makes images useful
-for a cache: save a document the first time it is parsed (to a file, a shared-memory segment, an in-process cache),
-and [`load()`](../api/basic_json_document/load.md) it on every later use instead of parsing the source text again.
-They are just as useful for handing a parsed document to another process (or a forked worker) running the same build
-of the library, since [`load()`](../api/basic_json_document/load.md) turns the transfer into a copy of the node index
-plus pointers into the received bytes, not a re-parse.
-
-**Choosing a check.** [`load()`](../api/basic_json_document/load.md) takes an
-[`image_check`](../api/basic_json_document/load.md#image_check) that trades validation against speed:
-`image_check::full` (the default) checks everything the parser itself guarantees, so a checked image is exactly as
-safe to read and serialize as a freshly parsed document -- the right choice whenever the image did not come straight
-from this process's own [`save()`](../api/basic_json_document/save.md), such as a file or a network peer.
-`image_check::bounds` only checks structure and bounds -- cheaper, since it skips scanning the text and the decoded
-strings -- and fits a cache the process trusts, one it wrote and reads back itself. `image_check::none` skips
-validation entirely, for an image trusted as much as the process's own memory. See
-[`load()`'s Notes](../api/basic_json_document/load.md#notes) for exactly what each level does and does not guarantee.
-
-??? example "Example: cache a parsed configuration as an image"
-
-    ```cpp
-    --8<-- "examples/basic_json_document__save.cpp"
-    ```
-
-    Output:
-
-    ```json
-    --8<-- "examples/basic_json_document__save.output"
-    ```
-
-!!! warning "Experimental"
-
-    The image format is versioned but not yet stable, and may change in an incompatible way before it is declared
-    stable. It is little-endian only, and tied to the library build that wrote it -- use it to cache a document or to
-    hand one to another process running the *same* build, not as a long-term storage format; keep the original JSON
-    text if a saved document needs to be readable by a future library version.
-
-The idea of a document you can read without parsing comes from zero-copy formats such as
-[FlatBuffers](https://github.com/google/flatbuffers) and [YaFF](https://github.com/yandex/yaff); the check
-[`load()`](../api/basic_json_document/load.md) runs follows the idea of FlatBuffers' Verifier. No code is taken from
-either.
-
 ## Choosing between `json`, `ordered_json`, the SAX interface, and `json_view`

 | | [`json`](../api/json.md) / [`ordered_json`](../api/ordered_json.md) | [SAX interface](parsing/sax_interface.md) | [`json_document`](../api/json_document.md) / [`json_view`](../api/json_view.md) | [`json_editable_document`](../api/json_editable_document.md) / [`json_editable_view`](../api/json_editable_view.md) |
@@ -371,7 +320,6 @@ either.
 | **Mutability** | freely mutable | not applicable (a one-shot event stream) | read-only | [`set`](../api/basic_json_document/set.md)/[`push_back`](../api/basic_json_document/push_back.md)/[`insert`](../api/basic_json_document/insert.md)/[`erase`](../api/basic_json_document/erase.md) edit in place; the source text is never rewritten |
 | **What you get** | a full tree you can read, write, and keep as long as you like | a sequence of callbacks; whatever your handler builds from them | a flat index plus, on demand, [`materialize()`](../api/basic_json_view/materialize.md)d `json`/`ordered_json` values for the parts you actually use | the same, plus [`dump()`](../api/basic_json_view/dump.md) of an edited document that keeps the member order and, with [`number_format::source`](../api/basic_json_view/number_format.md), the spelling of every untouched number |
 | **Typical use** | general-purpose JSON handling: config, request/response bodies you build or modify, anything you hold onto | validating or projecting a text into your own data structure without ever holding the whole thing as JSON | large or high-volume input where you only need part of it, or need it repeatedly, and can keep the source text (or a copy) alive for as long as the document lives | a document you read, patch a few fields of, and write back -- a configuration file, for instance -- where the rest of it should come back exactly as it was |
-| **Caching/reload** | not applicable -- re-parse, or roll your own serialization | not applicable | [`save()`](../api/basic_json_document/save.md)/[`load()`](../api/basic_json_document/load.md): cache the parsed index as an image and reload it without parsing | same, saving the document's current -- possibly edited -- state |

 ## Version history

@@ -51,16 +51,16 @@ If you do want to preserve the **insertion order**, you can use the type [`nlohm
    --8<-- "examples/ordered_json.output"
    ```

-Alternatively, [`nlohmann::fifo_map`](https://github.com/nlohmann/fifo_map) also preserves the insertion order and, unlike [`ordered_map`](../api/ordered_map/index.md), keeps a lookup index, so it does not have the quadratic cost described below. It is used through a small adapter ([integration](https://github.com/nlohmann/json/issues/485#issuecomment-333652309)).
+Alternatively, [`nlohmann::fifo_map`](https://github.com/nlohmann/fifo_map) also preserves the insertion order and, unlike [`ordered_map`](../api/ordered_map.md), keeps a lookup index, so it does not have the quadratic cost described below. It is used through a small adapter ([integration](https://github.com/nlohmann/json/issues/485#issuecomment-333652309)).

 If the order does not matter and you only want faster lookup, `boost::unordered_flat_map`, `absl::flat_hash_map`, `absl::node_hash_map`, and several other hash maps work through an adapter that restores the template argument order `basic_json` expects; see [Template Parameter Requirements](types/template_parameters.md#objecttype). Note these are *unordered*, not insertion-ordered.

 [`tsl::ordered_map`](https://github.com/Tessil/ordered-map) cannot be used: its iterators expose the mapped value as `const`, while `basic_json` needs to modify it in place.

-The [`ordered_map`](../api/ordered_map/index.md) behind `nlohmann::ordered_json` is deliberately minimal and has no lookup
+The [`ordered_map`](../api/ordered_map.md) behind `nlohmann::ordered_json` is deliberately minimal and has no lookup
 index, so every key access is a linear scan and building an object of `n` keys costs O(n²). This is unnoticeable at
 typical object sizes but becomes significant for objects with many thousands of keys; see
-[`ordered_map` complexity](../api/ordered_map/index.md#complexity). The alternatives above keep a lookup index and do not
+[`ordered_map` complexity](../api/ordered_map.md#complexity). The alternatives above keep a lookup index and do not
 have this cost.

 ### Notes on parsing
@@ -94,10 +94,10 @@ whether it is worth the loss of human readability at all -- depends on the actua
 The default [`json`](../api/json.md) type stores object keys in a `#!cpp std::map`, giving logarithmic-time lookup,
 insertion, and erasure, at the cost of sorting keys alphabetically rather than preserving insertion order (see
 [Object Order](object_order.md)). [`ordered_json`](../api/ordered_json.md) uses
-[`nlohmann::ordered_map`](../api/ordered_map/index.md) instead, a `#!cpp std::vector`-backed container with no lookup index:
+[`nlohmann::ordered_map`](../api/ordered_map.md) instead, a `#!cpp std::vector`-backed container with no lookup index:
 every key-based operation is a **linear scan**, so building an object of `n` distinct keys costs **O(n²)** in total --
 this applies equally to inserting keys one by one and to parsing an object, since the parser inserts each key as it is
-read. The [measurements on the `ordered_map` page](../api/ordered_map/index.md#complexity) show this is
+read. The [measurements on the `ordered_map` page](../api/ordered_map.md#complexity) show this is
 negligible at typical object sizes (2000 keys: 0.7 ms for `json` vs. 3.6 ms for `ordered_json`, a 5x factor) but grows
 steeply for large, machine-generated objects (16 000 keys: 3.3 ms vs. 181.6 ms, a 54x factor).

@@ -42,7 +42,7 @@ Requirements are split into two groups:

 | Template parameter                                                | Default                           | Notable substitutes                                                                              |
 |-------------------------------------------------------------------|-----------------------------------|--------------------------------------------------------------------------------------------------|
-| [`ObjectType`](#objecttype)                                       | `std::map`                        | [`nlohmann::ordered_map`](../../api/ordered_map/index.md), Abseil hash maps                            |
+| [`ObjectType`](#objecttype)                                       | `std::map`                        | [`nlohmann::ordered_map`](../../api/ordered_map.md), Abseil hash maps                            |
 | [`ArrayType`](#arraytype)                                         | `std::vector`                     | `#!cpp std::deque`                                                                               |
 | [`StringType`](#stringtype)                                       | `std::string`                     | `std::string`-like types over `char`                                                             |
 | [`BooleanType`](#booleantype)                                     | `bool`                            | none worth using                                                                                 |
@@ -235,7 +235,7 @@ The library does not sort or de-duplicate keys itself; the behavior described in
 | Container                                                                        | Notes                                                                         |
 |----------------------------------------------------------------------------------|-------------------------------------------------------------------------------|
 | `#!cpp std::map` (default)                                                       |                                                                               |
-| [`nlohmann::ordered_map`](../../api/ordered_map/index.md)                              | used by [`ordered_json`](../../api/ordered_json.md); keeps insertion order    |
+| [`nlohmann::ordered_map`](../../api/ordered_map.md)                              | used by [`ordered_json`](../../api/ordered_json.md); keeps insertion order    |
 | [`nlohmann::fifo_map`](https://github.com/nlohmann/fifo_map)                     | keeps insertion order; adapter puts `fifo_map_compare` in the comparator slot |
 | `boost::container::map`, `boost::container::flat_map`                            | no adapter needed                                                             |
 | `#!cpp std::unordered_map`                                                       | through the adapter above; not with libstdc++ 9, see the note                 |
@@ -50,7 +50,7 @@ The public headers are in [`include/nlohmann`](https://github.com/nlohmann/json/
 - [`adl_serializer.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/adl_serializer.hpp), [`byte_container_with_subtype.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/byte_container_with_subtype.hpp), and [`ordered_map.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/ordered_map.hpp) define
  [`adl_serializer`](../api/adl_serializer/index.md),
  [`byte_container_with_subtype`](../api/byte_container_with_subtype/index.md), and
-  [`ordered_map`](../api/ordered_map/index.md).
+  [`ordered_map`](../api/ordered_map.md).
 - [`json_view.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/json_view.hpp) is a separate,
  optional header that defines [`basic_json_document`](../api/basic_json_document/index.md) and
  [`basic_json_view`](../api/basic_json_view/index.md), a flat-index, read-only, non-owning way to look at a parsed
@@ -104,7 +104,7 @@ from `json_view.hpp` and `detail/view/`.
 The library provides two specializations:

 - [`json`](../api/json.md) uses all default template arguments.
- [`ordered_json`](../api/ordered_json.md) uses [`ordered_map`](../api/ordered_map/index.md) as `ObjectType` to keep the
+- [`ordered_json`](../api/ordered_json.md) uses [`ordered_map`](../api/ordered_map.md) as `ObjectType` to keep the
  insertion order of object keys.

 The requirements on the template arguments are listed in
@@ -262,14 +262,6 @@ edited:
 - Views of read-only documents compile without any of this: how views walk the index is a template parameter
  (`navigation<Editable>`).

-Images ([`save`](../api/basic_json_document/save.md) and [`load`](../api/basic_json_document/load.md),
-[`detail/view/image.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/view/image.hpp)) store
-the nodes as they are: a 64-byte header (the magic bytes `NJVI`, a format version, the sizes, and reserved bytes that
-must be zero), the nodes, the text, and the decoded strings. An edited document is first written in document order, as
-the parser would have written it (without links), and the numbers of the hash indexes are cleared, since `load`
-rebuilds the indexes. So a change of the node layout is a change of the image format: it must raise `image_version`,
-and `load` then rejects images of other versions (`parse_error.116`) instead of misreading them.
-
 ## Input adapters

 Input is read via **input adapters** that abstract a source. Every input adapter provides this interface:
@@ -395,23 +395,6 @@ A UBJSON high-precision number could not be parsed.
    [json.exception.parse_error.115] parse error at byte 5: syntax error while parsing UBJSON high-precision number: invalid number text: 1A
    ```

-### json.exception.parse_error.116
-
-[`basic_json_document::load()`](../api/basic_json_document/load.md) rejected an
-[image](../features/json_view.md#images): either the bytes are not one [`save()`](../api/basic_json_document/save.md)
-could have written (too short, an unknown magic number or format version, or sizes that do not fit the buffer), or
-they are, but fail the requested [`image_check`](../api/basic_json_document/load.md#image_check).
-
-!!! failure "Example message"
-
-    ```
-    [json.exception.parse_error.116] parse error: invalid json_document image: the check failed
-    ```
-
-!!! note
-
-    This exception was added in version 3.13.0, together with [images](../features/json_view.md#images).
-
 ## Iterator errors

 This exception is thrown if iterators passed to a library function do not match
@@ -848,26 +831,6 @@ from JSON text.

    This exception was added in version 3.13.0, together with editable [`json_document`s](../features/json_view.md).

-### json.exception.type_error.320
-
-[`basic_json_document::save()`](../api/basic_json_document/save.md) cannot write an
-[image](../features/json_view.md#images) of a [discarded](../api/basic_json_document/is_discarded.md) document.
-[`save()`](../api/basic_json_document/save.md) and [`load()`](../api/basic_json_document/load.md) also throw this
-exception on a big-endian target, since the image format is little-endian only.
-
-!!! failure "Example messages"
-
-    ```
-    [json.exception.type_error.320] cannot save a discarded json_document
-    ```
-    ```
-    [json.exception.type_error.320] json_document images need a little-endian target
-    ```
-
-!!! note
-
-    This exception was added in version 3.13.0, together with [images](../features/json_view.md#images).
-
 ### json.exception.type_error.321

 A discarded value (one created by [`parse()`](../api/basic_json/parse.md) with a callback that returns `false` for the
@@ -972,19 +935,9 @@ double-precision number when `number_float_t` is `#!cpp float`.

 ### json.exception.out_of_range.407

-An integer number cannot be represented by the binary format it is serialized to:
-
- [BON8](../features/binary_formats/bon8.md) only stores integers that fit into int64, so
-  [`to_bon8`](../api/basic_json/to_bon8.md) throws for unsigned integers greater than 9223372036854775807.
- [CBOR](../features/binary_formats/cbor.md), [MessagePack](../features/binary_formats/messagepack.md), and
-  [BSON](../features/binary_formats/bson.md) store integers in at most 64 bits. With the default number types, every
-  integer fits, but a [`number_integer_t`](../api/basic_json/number_integer_t.md) or
-  [`number_unsigned_t`](../api/basic_json/number_unsigned_t.md) wider than 64 bits (e.g., `__int128`) can hold values
-  outside the range of the format: [-2^64, 2^64-1] for CBOR, [-2^63, 2^64-1] for MessagePack, and the range of int64
-  (signed integers) or uint64 (unsigned integers) for BSON.
-
-[UBJSON](../features/binary_formats/ubjson.md) and [BJData](../features/binary_formats/bjdata.md) never throw this
-exception, because they serialize integers beyond 64 bits as high-precision numbers.
+An unsigned integer number greater than 9223372036854775807 cannot be represented in the binary format. This exception
+is only thrown by [`to_bon8`](../api/basic_json/to_bon8.md), as [BON8](../features/binary_formats/bon8.md) has no
+unsigned 64-bit integer type.

 !!! note "Former occurrences"

@@ -993,17 +946,11 @@ exception, because they serialize integers beyond 64 bits as high-precision numb
    - Since version 3.9.0, integer numbers beyond int64 are serialized as high-precision UBJSON numbers.
    - Since version 3.12.0, integer numbers beyond int64 are serialized as uint64 BSON numbers.

-    Before version 3.13.0, CBOR, MessagePack, and BSON silently truncated integers wider than 64 bits, and BJData
-    truncated unsigned integers wider than 64 bits.
-
-!!! failure "Example messages"
+!!! failure "Example message"

    ```
    integer number 18446744073709551615 cannot be represented by BON8 as it does not fit int64
    ```
-    ```
-    integer number 1267650600228229401496703205376 cannot be represented by CBOR as it does not fit [-2^64, 2^64-1]
-    ```

 ### json.exception.out_of_range.408

@@ -1141,9 +1088,7 @@ MessagePack's ext type and BSON's binary subtype are each stored in a single byt
 so they do not support an input of 4294967280 bytes (4 GiB minus 16 bytes) or more. The same 32-bit limit applies to an **editable** document's own
 storage: [`set`](../api/basic_json_document/set.md) and [`push_back`](../api/basic_json_document/push_back.md) throw
 this exception once the strings and number tokens written by edits reach 4 GiB in total, or once more than
-4294967295 arrays/objects have had an element set or appended to them. The same limit applies to an
-[image](../features/json_view.md#images): [`save()`](../api/basic_json_document/save.md) throws it if the node
-count, the text, or the decoded strings it would write would individually reach 4 GiB.
+4294967295 arrays/objects have had an element set or appended to them.

 !!! failure "Example messages"

@@ -1153,9 +1098,6 @@ count, the text, or the decoded strings it would write would individually reach
    ```
    [json.exception.out_of_range.416] edits of 4 GiB or more are not supported by json_document
    ```
-    ```
-    [json.exception.out_of_range.416] images of 4 GiB or more are not supported by json_document
-    ```

 !!! note
				`@@ -1 +0,0 @@`
				`Container is std::vector<std::pair<const Key, T>>: true`