Feature request: Make it header-only

[jmuncaster]

Thank you for your excellent library. One convenient characteristic of nlohmann/json is the fact that it is header-only. Are there any plans to do this?

[pboettch]

Thanks for this feature request. First I want to say, that there is another, header-only, JSON schema validation called valijson which supports NLohmann's JSON-library.

Now to answer your question: it would be possible to change the current code to make it header-only. But IMO, the current way things are done is not very well adapted to be header-only. Currently the schema is read and parsed and then a validator-object is created, which can then be used to validate JSON-objects - several times.

Code which uses the object, does not need to have access to validator-creation-code. If everything is in a header-file which is included in every user-code, it would lengthen compilation-time for nothing.

So, if the current code would be transformed to be header-only, I still would opt for a json-schema.h and a json-schema-code.h-file. The second file would be included by the user-code which creates the validator-object.

However, since some time, in a background-thread, I'm thinking about a new version, which would be header-only and would be using more advanced, modern C++-features. The principle goal would be to do much faster validations, because let's face it, the current implementation is slow.

[RPGillespie6]

I actually hate that nlohmann is header only because it means every single process that uses it gets a separate copy of the entire library which is bad in embedded. If you decide to provide this feature, please also leave the option to build as a shared object like you currently have.

[pboettch]

The big advantage of header-only is, that compilers have the full view and can optimize. For a strongly templated library like nlohmann::json there is not much choice event.

Regarding embedded memory-footprint, normally good compiler today add the linkonce-flag to symbols which are the result of templated functions and methods. And when doing the final link, they use only one instance.

The only real drawback I can see is compile-time, but who cares, if the code running on the user's side is faster in the end.

[RPGillespie6]

My point is more like: say you have a collection of processes in your raspberry pi: a, b, c, d.

All 4 of these processes need JSON parsing/serialization, so all 4 #include <nlohmann/json.hpp>. Now it's as if you've statically linked the library 4 times taking up 4x the flash and RAM footprint, vs. creating a single shared object that all 4 processes can share (saving both flash and RAM).

This is especially important satellite systems, where not only are the flash and RAM constained in the modem, but also every byte transferred over the network (for downloadable updates or whatever) must go to space and back.

Now imagine if every library did this, and not just nlohmann/json. Your system applications image would bloat to kN the size, where N is the number of applications and k is some bloat constant.

[RPGillespie6]

I vote if you continue with this feature to do what sqlite does, and have a CMake option that generates a header-only library if you so choose by concatenating the source files together.

[pboettch]

I will take this requirement into consideration - every request is welcome, thanks.

[RPGillespie6]

FYI nlohmann/json uses amalgamate.py

[pboettch]

The new version won't be header-only. There is no reason to do so with the way I decided to write it, it would only bloat the final binary. As the new version is still a build-the-schema-validation-at-runtime-machine. Schema-optimizations won't really happen at compile-time.

[pboettch]

IMHO: header-only makes no sense for this kind of libraries.