r/cpp•
tucher_one

I tried building a “pydantic-like”, zero-overhead, streaming-friendly JSON layer for C++ (header-only, no DOM). Feedback welcome

Hi r/cpp

I’ve been experimenting with a C++23 header-only library called JsonFusion: your C++ types are the schema, and the library parses + validates + populates your structs in one pass (no handwritten mapping layer).

My motivation: there are already “no glue” typed approaches (e.g. Glaze, reflect-cpp) — but they are not a good fit for the small-embedded constraints I care about (streaming/forward-iterator parsing, avoiding heap usage / full buffering, and keeping template/code-size growth under control across multiple models). I also haven’t found anything with the full set of features I would like to have.
At the same time, the more “DOM-like” or token-based parsers (including popular embedded options like ArduinoJson/jsmn/cJSON) fundamentally push you into tradeoffs I wanted to avoid: either you preallocate a fixed DOM/token arena or you use the heap; and you almost always end up writing a separate, manual mapping + validation layer on top (which is powerful, but easy to get wrong and painful to maintain).

Repo/README: github.com/tucher/JsonFusion

Docs are still in process, but there’s a docs/ folder, benchmarks, and a test suite in the repo if you want to dig deeper.

What it tries to focus on (short version):

  • Zero glue / boilerplate: define structs (+ optional annotations) and call Parse().
  • Validation as a hard boundary: you either get a fully valid model, or a detailed error (with JSON path).
  • No “runtime subsystem”: no allocators/registries/config; behavior is driven by the model types.
  • Streaming / forward-iterator parsing: can work byte-by-byte; typed streaming producers/consumers for O(1) memory on non-recursive models.
  • Embedded friendliness: code size benchmarks included (e.g. ~16–21KB .text on Cortex-M with -Os, ~18.5KB on ESP32 -Os in the provided setup).
  • CBOR support: same model/annotations, just swap reader/writer.
  • Domain types are intentionally out of scope (UUID/date/schema algebra, etc.) — instead there are transformers to compose your own conversions.

Important limitations / caveats:

  • GCC 14+ only right now (no MSVC/Clang yet).
  • Not a JSON DOM library (if you need generic tree editing, this isn’t it).
  • There’s an optional yyjson backend for benchmarking/high-throughput cases, but it trades away the “no allocation / streaming” guarantees.

I’m not claiming it’s production-ready — I’d love feedback on:

  • API/ergonomics (especially annotations/validation/streaming)
  • C integration / interoperability approach (external annotations for “pure C” structs, API shape, gotchas)
  • what limitations are unacceptable / what’s missing
  • compile times / template bloat concerns
  • whether the embedded/code-size approach looks sane

Thanks for reading — the README is the best entry point, and I’m happy to adjust direction based on feedback.

Posted Dec 29, 2025, 7:48 PM UTC

2120
Loading comments…