You could try tinyXML.

I use (and even donate to) https://github.com/nlohmann/json for JSON. It's header-only, no library, no subproject, no dependencies, no complex build system. The class is written in vanilla C++11. It's insanely well-tested, and is full of features. It's one of my favorite libraries on the internet as an example of what great software design looks like in terms of expected features, error messages, simplicity, test coverage, etc.

To convert or parse your custom object to/from JSON, you would write to_json and from_json functions. Note if the object you are parsing is in a namespace, these functions you create must also be in that namespace.

Here's an example going to and from an ALLEGRO_COLOR:

With those functions, you might save/load the data through files like this:

Running the program, your output might look like this:

My color, loaded from a JSON file is:
  r: 0.2
  g: 0.6
  b: 0.4
  a: 1

and the foobar.json file that was written might look like this:

{
   "my_color": {
      "a": 1.0,
      "b": 0.4000000059604645,
      "g": 0.6000000238418579,
      "r": 0.20000000298023224
   }
}

I'll look into nlohmann. the JSON library I'm using doesn't have write capability.
Not fond of the from_json with void return. What if there was an issue grabbing from the file?

My library was written ~ 2014 and had a few errors with certain functionality removed. Next chance I get I'll see what they were to give you a better picture of what I mean.

Plus, while I was looking at the code to see if I could fix it, I decided I wasn't happy with it. The library was bulky. I am on the fence on what is deemed "better" practice. I know it's subjective. Do I add bulky object functionality or keep them barebone? I'm leaning towards barebone at the moment.

Plus with all the new functionality, I thought I could make it better/cleaner.

Made the plunge. Took a few hours, but have everything converted over.

There was even a NuGet package for it.

A bit of a learning curve, and I documentation is overwhelming.

Thanks,

No, not quite useful.

Years ago I was messing with android programming. They use a manifest.xml that specifies any addons, app type, etc.

I thought it was a good way to initialize an Allegro program. Easier for the end-user. It parses a file and does all the background work (initializes addons, creates a display, event queue, and any timers). Also load any initial objects (bitmaps, fonts, etc).

I have a series of functions that parses json objects.

ALLEGRO_BITMAP* parse(json data);
// etc

I also have a resource handler that manages those objects. If I need an object, I just grab it. If it doesn't exists then it loads it for me.

//  set 'keep' to true if the handler manages deletion
ALLEGRO_BITMAP *grab(handler *h, const std::string& id, bool keep);

I thought about it, but wasn't sure if nesting is possible. That's why I originally went with xml.

json is simple. just a load of pairs with a key and an object, which could be a set of objects {}, an array [] or a value "".

Here is my manifest.json file. I like the simplicity and cleaner look over xml. The only thing is missing is ability to add comments. I could add a comment object and make sure my program ignores it.

For JSON in C, I use cJSON, and it's pretty good IMHO. (you can find it here: https://github.com/DaveGamble/cJSON )

I recently discovered that KAFKA's librdkafka is also using it (while building on RedHat 7, because the provided librdkafka is way too old, like from 2018).

That aside, it fits my needs, which are maybe simpler than others. cJSON is just a header and a c file.