json VS strictyaml

I have not done a "desktop" program in 25+ years and never using C++ (or C), since then I'm mostly a web developer (PHP,Elixir, JS, Kotlin etc).

I'm currently doing a C++ audio plugin with the Juce framework.

This website has been a good resource, alongside https://www.learncpp.com

But I was actually close to give up before using those two things:

- https://github.com/nlohmann/json : my plugin use a json api backend and the Juce json implementation is atrocious (apparently because of being born in previous c++ version), but this library is GREAT.

- ChatGPT 4. I'm not sure I would have "succeeded" without it, at least not in a reasonable time frame. ChatGPT 3.5 is slow and does not give good results for my use case but 4 is impressive. And I use in a very dumb way, just posing question in the web UI. I probably could have it directly in MSVC?

Also I must say, for all its flaws, I have a renewed appreciation for doing UI on the web ;)

https://github.com/nlohmann/json works well for me

cmake_minimum_required(VERSION 3.15) project(xrpc++ DESCRIPTION "C++ AT Protocol XRPC library" VERSION 1.0.0 LANGUAGES CXX) include(FetchContent) FetchContent_Declare(cpr GIT_REPOSITORY https://github.com/libcpr/cpr.git GIT_TAG 2553fc41450301cd09a9271c8d2c3e0cf3546b73) # The commit hash for 1.10.x. Replace with the latest from: https://github.com/libcpr/cpr/releases FetchContent_MakeAvailable(cpr) FetchContent_Declare(json URL https://github.com/nlohmann/json/releases/download/v3.11.2/json.tar.xz) FetchContent_MakeAvailable(json) add_library(${PROJECT_NAME} SHARED src/lexicon.cpp src/xrpc.cpp ) target_link_libraries(${PROJECT_NAME} PRIVATE cpr::cpr) target_link_libraries(${PROJECT_NAME} PRIVATE nlohmann_json::nlohmann_json) set_target_properties(${PROJECT_NAME} PROPERTIES VERSION ${PROJECT_VERSION}) set_target_properties(${PROJECT_NAME} PROPERTIES SOVERSION 1) target_include_directories(${PROJECT_NAME} PUBLIC include) set(CMAKE_BUILD_TYPE debug)

FetchContent_Declare(json URL https://github.com/nlohmann/json/releases/download/v3.11.2/json.tar.xz) FetchContent_MakeAvailable(json)

Here is one popular C++ library (nlohmann/json) removing its use.

Before going into binary serialization I suggest you to get comfortable with serialization to text. You can try to write your data to text files and read them in again. Then after you get an idea of how this works you can try to use a library that writes to XML or json, e.g. nlohmann json

Download the single header file json.hpp from https://github.com/nlohmann/json/releases and place it in your project directory or an include directory.

Exemple of a JSON library: https://github.com/nlohmann/json (For XML, there's tinyxml)

NestedText already is the way I use YAML; everything is intepreted as a string. I have some trust in my YAML parser to not mangle most strings. I could use NestedText, but users would be unfamiliar with it, and IIRC the only parsers are in Python. But then I could use StrictYaml too https://github.com/crdoconnor/strictyaml

you can stick to a subset of YAML syntax (e.g. strictYAML)

YAML stands for "YAML Ain’t Markup Language" - this is known as a recursive acronym. YAML is often used for writing configuration files. It’s human readable, easy to understand and can be used with other programming languages. Although YAML is commonly used in many disciplines, it has received criticism on the amoutn of whitespace .yml files have, difficulty in editing, and complexity of the standard. Despite the criticism, properly using YAML ensures that you can reproduce the results of a project and makes sure that the virtual environment packages play nicely with system packages. (If you're looking for another way to share environments there are other alternatives to YAML which include StrictYAML (a type-safe YAML parser) and NestedText)

The example you linked provides this as an example of a YAML document that he wants his format to support.

That safe subset exists and is implemented in a number of languages. It is called strict-yaml: https://hitchdev.com/strictyaml/

StrictYAML\ (33 comments)

To me those are in the category of "nice to have", and the problem is that every developer has different preferences for these [1] [2]. But the main features of StrictYaml, like supporting comments and less syntactic noise, I think are pretty uncontroversial, and perhaps it's worth it to get people to switch over for those alone. It doesn't need to be perfect, it just needs to be a significant enough improvement over JSON, and I'd say those two features are more than enough

[1]: https://github.com/crdoconnor/strictyaml/issues/37

[2]: https://github.com/crdoconnor/strictyaml/issues/38