3 ms·

Json is easier for humans to read and modify, and it's more straightforward to work with in languages like python where you don't have to declare types. Json c+

Json is easier for humans to read and modify, and it's more straightforward to work with in languages like python where you don't have to declare types. Json c++ implimentation is large probably because of trying to provide one library that does all the dynamic things json can do, but in a static language. It also has to be safe to parse, so there's that.

CoolGuySteve 7y ago
For config files at least, I've moved entirely to ini format. Python's configparser is handy for machine generating complicated configs and the nesting/list support in JSON adds way more complexity than I need compared to just using comma separated lists as values. This is my entire ini parser for making a std::map<std::string, std::string>. I cast/parse the values at the use site: std::regex section_test("\\[(.*?)\\]"); std::regex value_test("([\\w\\.]+)\\s*=\\s*([^\\+]+(?!\\+{3}))"); while(-1 != getline((char**)&buf, &len, file)) { std::string line(buf); trim(line); if(!line.size() || line[0] == '#') continue; std::smatch match; if(std::regex_search(line, match, section_test)) current_section = match[1].str(); else if(std::regex_search(line, match, value_test)) { std::string key(match[1].str()); std::string value(match[2].str()); info("INIReader: %s::%s = %s\n", current_section.c_str(), key.c_str(), value.c_str()); config[current_section][key] = value; } }
- umvi 7y ago
  This has to pull in std::regex though which is pretty heavy
  - CoolGuySteve 7y ago
    std::regex is part of c++11 anyways so there's nothing to integrate with your build system. I put this code in a standalone cpp file so that it compiles to its own object in parallel with the rest of the system. I've never had issues with it with regards to build times.
- theamk 7y ago
  Our project is using something like that - it started nice and simple, but got lots of ugly hacks now. We have some values which use two different sub-delimiters, multiple “mini-formats”, values which contain the name of other keys, magic atrings to represent “null”, and so on. We got used to this, but results are pretty ugly. We get people confused about delimiter order, broken copy-paste, and so on. For the next project, I’d recommend something which can support complex structures. A schema validation would be nice, too.

CoolGuySteve 7y ago

For config files at least, I've moved entirely to ini format. Python's configparser is handy for machine generating complicated configs and the nesting/list support in JSON adds way more complexity than I need compared to just using comma separated lists as values. This is my entire ini parser for making a std::map<std::string, std::string>. I cast/parse the values at the use site: std::regex section_test("\\[(.*?)\\]"); std::regex value_test("([\\w\\.]+)\\s*=\\s*([^\\+]+(?!\\+{3}))"); while(-1 != getline((char**)&buf, &len, file)) { std::string line(buf); trim(line); if(!line.size() || line[0] == '#') continue; std::smatch match; if(std::regex_search(line, match, section_test)) current_section = match[1].str(); else if(std::regex_search(line, match, value_test)) { std::string key(match[1].str()); std::string value(match[2].str()); info("INIReader: %s::%s = %s\n", current_section.c_str(), key.c_str(), value.c_str()); config[current_section][key] = value; } }

umvi 7y ago
This has to pull in std::regex though which is pretty heavy
- CoolGuySteve 7y ago
  std::regex is part of c++11 anyways so there's nothing to integrate with your build system. I put this code in a standalone cpp file so that it compiles to its own object in parallel with the rest of the system. I've never had issues with it with regards to build times.
theamk 7y ago
Our project is using something like that - it started nice and simple, but got lots of ugly hacks now. We have some values which use two different sub-delimiters, multiple “mini-formats”, values which contain the name of other keys, magic atrings to represent “null”, and so on. We got used to this, but results are pretty ugly. We get people confused about delimiter order, broken copy-paste, and so on. For the next project, I’d recommend something which can support complex structures. A schema validation would be nice, too.