Just looking for advice on what to do.

Years ago, I wrote a library with an XML parser that would take a file and create the application as it was parsed. It would create the display, event queue, timers, etc. I wanted something I could change the conditions without recompiling. It worked very well.

I got the bug again and wanted to continue where I left off. However, with all the changes to C++ since, it doesn't work anymore. I could revert to an older C++, but instead I started over.

I didn't want to rewrite the xml parser again so I was looking for alternatives. XML, YAML, JSON,

I went with JSON and found a light-weight parser. Very light-weight.

I already reported a bug with parsing escape characters and I have no way of checking if an object is an array or a set of objects themselves. Even an extra comma in the wrong place crashes the parser with no indication where the issue lies.

Otherwise, the parser is great. I did modify it some. I put it all in its own namespace and removed the RSJ prefix.

What to do? continue, find a different parser, attempt to modify his parser?

I could try to add some functions like is_array or is_object. But his code is a bit messy. I hate messy code.

You could try tinyXML.

For Json I usually use quicktype purely because if you can pump the Json into the left hand window and then have all the needed code generated for you (or just the parser); although I only use it with C# which is a lot more straightforward (IMHO) than implementing it in C++.

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 also have used nlohmann json. It's very good, I recommend it. TinyXML2 also works nicely if you want to stick to XML.

This surprises me; compatibility is one of the things C++ tries very hard to do

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.

to_json and from_json don't grab from a file. The file interfacing is entirely up to you to implement if you wish.

If you want to be certain that the fields you expect exist in the JSON object, you can check with .contains("my_color"). You can then handle it however you want.

If there's an error parsing JSON from an invalid JSON string, then nolhmann will raise a parse error, which you can catch. It has detailed information. For example, if I were to parse a string containing this invalid JSON:

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

It would throw this error:

terminating with uncaught exception of type nlohmann::detail::parse_error: [json.exception.parse_error.101] parse error at line 2, column 4: syntax error while parsing value - invalid literal; last read: '<U+000A>   m'

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,

Also, if you're interested, Python has good JSON parsing. Though a scripting language may not be right for your project.

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 generally use a config file for setup. Easy map like language.

if (config["Graphics"]["Fullscreen"] == std::string("1")) {
   fullscreen = true;
}

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.

I'll check out nlohmann's library. I like that it's header only, that's a good call.

So far I've used my own JSON parser, mainly because I didn't want to bother with compiling yet another dependency. Dependencies are such a pain in C++, to the point where you prefer to write your own code rather than deal with that.

My own implementation is tested well enough. So far it works with all the JSON I've thrown at 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.