beached

daw_json_link

C++2019–2024

beached / daw_json_link

daw_json_link

Fast, convenient JSON serialization and parsing in C++

Languages & Compilers Data & Databases

Explore on GitHub Read Hacker News discussions

4Distinct people

10Mentions

0Explicit recommenders

514GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Fast, convenient JSON serialization and parsing in C++

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year10 dated mentions

Observed mentions: 2019-08-16 15:04:32 UTC to 2024-11-14 07:32:54 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	0	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	0	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	3	1	2
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	5	0	5

What Hacker News says

10 sources

leni536·Nov 14, 2024

On the other end of the spectrum there is [1]. It's both performance and usability oriented, although compile times are probably higher. Nlohmann is the slowest out of the popular libraries, AFAIK, and not particularly more usable than rapidjson, in my experience. So "better than nlohmann" is not very novel. [1] https://github.com/beached/daw_json_link

In JSON for Classic C++

westurner·Aug 5, 2024

"Exporting JSON Schema" https://github.com/beached/daw_json_link/blob/release/docs/c... : include <daw/json/daw_json_schema.h> std::string daw::json::to_json_schema<MyType>( "identifier", "title" ); From https://westurner.github.io/hnlog/#comment-38526588 : > SHACL is used for expressing integrity constraints on complete data, while OWL allows inferring implicit facts from incomplete data; SHACL reasoners perform validation, while OWL reasoners do logical inference. - "Show HN: Pg_jsonschema – A Postgres extension for JSON validation" https://news.ycombinator.com/item?id=32186878 re: json-ld-schema, which bridges JSONschema and SHACL for JSONLD

In Enum class improvements for C++17, C++20 and C++23

beached_whale·Aug 4, 2024

re Serde: If you want JSON, https://github.com/beached/daw_json_link is about as close as we can get. It interop's well with the reflection(or like) libraries such as Boost Describe or Boost PFR and will work well with std reflection when it is available.

In Enum class improvements for C++17, C++20 and C++23

leni536·Jul 10, 2024

This lib does something like that: https://github.com/beached/daw_json_link

In Compile-time JSON deserialization in C++

beached_whale·Jul 2, 2024

They exist, for instance https://github.com/beached/daw_json_link , uses mappings of JSON <-> class members/construction. It handles a bunch of types out of the box and allows custom types to be mapped. Also, it integrates with some of the reflection like libraries out there now(Boost.Describe/Boost.PFR) and will be trivial to add C++26 static reflection when available. Because the library doesn’t need to allocate unless the underlying types being parsed to do, it has been constexpr since C++17 too. A bunch of people have used libraries that use macros for reflection like or PFR to integrate other C++ JSON Libraries too.

In Reflection for C++26

beached_whale·Aug 12, 2022Submission

Show HN: DAW JSON Link

I just released v3 of DAW JSON Link https://github.com/beached/daw_json_link, a C++ JSON library, that I am the author of. It's a C++ JSON library that prioritizes concrete data structures. It is fast, GB/s, and competitive with other libraries out there like simdjson. A brief list of things it supports are: * declaratively map json objects to C++ data structures * allows allocators to be provided and passes it to allocator aware types * can parse via a non-owning json_value that allows JSON Path like indices along with iteration of sub members * types to provide iteration over json arrays and use in C++ algorithms * JSON Lines/NDJSON support * The parser does not allocate at all, that is up to the resulting data structures, if needed. The memory usage is very minimal * Variants/Sum types are a priority and most express

Read the rest

ions of them in JSON have easy mappings with a fallback to code if needed * JSON Schema output from mappings * Custom number types are supported(e.g Boost Multi-precision/GNU MP) * Serialization to most things is supported out of the box with the ability to easily add a new way. This includes, pointer, output iterators, span like types, strings/vectors/containers of byte like types, FILE ... An accompanying project https://github.com/beached/daw_json_link_describe that allows using Boost.Describe reflection like mappings with JSON Link * Lots of example code in tests folder and cookbook like documentation in the docs folder to see it in use. All the examples in documentation are part of the test suite too * Optionally allows for comments( # line comments and C-style // and /* /) Allows for trailing comma * constexpr

3 points · Open discussion

leni536·Jan 2, 2022

Check out https://github.com/beached/daw_json_link , it provides a non-typeerased way to parse JSON straight into user-defined data structures.

In Deserializing JSON Fast (2020)

beached_whale·Jan 2, 2022

Not Rust, but for C++ I have found a lot of memory and CPU perf can be realized by knowing what is being parsed into and using that. Most JSON parsing optimize on array/object/number/bool/null and not things like unsigned integer being much faster to parse than a float(floating point hit cpu bottlenecks around 1GB/s). Additionally, allowing for compile time options to further optimize is much easier. Essentially most JSON parsers are type erased. https://github.com/beached/daw_json_link So this correlates with some of the findings the post has. One optimization that should show great promise is that if one knows that they have an array of some types like numbers/unsigned int/strings, that can greatly simplify and allow for SIMD'ification of it.

In Deserializing JSON Fast (2020)

nikki93·Sep 10, 2020

Yeah, I definitely care about performance more in that tradeoff. In my experience when performance matters, these details about using such a null representation and what different representations lend themselves also tends to matter. vs. gluing libraries to libraries willy-nilly. At that point this null issue is far from the main thing that comes up bc. you care about data layout enough that you have control over that representation. One example I'm running into in practice these days is--I'm using chipmunk2d game physics engine in a library. It does heap allocations, while all the component data for other stuff in my game tends go be well managed into pools that I can walk through contiguously. Even if I use a custom allocator for it, it uses pointers to refer between objects internally so I can't "move" instances of its eg. `cpBody` obj

Read the rest

ect around in memory. Would've been so nice to just own its data and let the library be layout-agnostic but alas. But yeah those are the data-data glues I've been interested in--libraries that kind of own representation but not location I guess. For your particular issue though, I think it really is bc. Lua is a language that out of the box doesn't tend to own representation, to the point of not eg. having its own class system etc, and it mostly shines when used in ways that play into that strength (eg. you want to wrap your own object ontology for ppl to script). The best libraries for Lua have tended to the invent their own representation and expect you to care about and own the mappings between libraries. esp. for JSON, the impedance mismatch with Lua tables puts it in this weird uncanny valley. Tbh my fav method of using JSON is to not have an in memory document format at all and just treat it as reader / writer objects directly into domain data so that you don't keep paying this intermediatw representation conversion cost. eg. https://github.com/beached/daw_json_link is interesting here In my own game stuff I just have game components accept reader/writer objects to read from / write to and each component tends to have domain logic about what it means to be missing something, what some defaults are, etc.

In Fennel – Lisp in Lua

beached_whale·Aug 16, 2019

It is template based so that each types JSON parser is statically known and to give the compiler more opportunity to optimize. https://github.com/beached/daw_json_link I haven't had a chance to look at why yet.

In The Order of the JSON