Config file parsers

[Stewbond]

Which configuration file format do you prefer?
INI, XML, JSON?

Which interpreters/parsers do you use?

[Stewbond]

I can't stand INI. There isn't really a standard parser for it and because of that, everyone adds their own flavor. When configuring these things, I always have troubles with stupid things that people just forget about when making their code: You need to have a newline after the last entry, you need to use tabs instead of spaces, etc.

I like XML. I've used the Oracle XML parser, RapidXML, TiNiXML, Qt XML and XmlLite. TiNi XML was by far the easiest. Also, it was really easy to integrate since it was just one source file and one header. They are all well documented. I know some people don't like using attributes, and would rather use nodes encompassing data, but I like to use attributes whenever there can only be one of an item in a structure.

The other thing about XML is that it's not as easy to write comments. Comments are part of the file structure and so you can't do anything inline. This is the big difference with JSON. However, it's very easy to save a file with comments as long as it was read and part of the structure.

I am about to try out JSON as I'm interface with another group who work entirely in JSON. I'm not sure how I'm going to store the comments in the file. It's meant to be manually edited, but should also be read, updated, and saved by the other group. I'm looking for a good parser to use here.

[CodeGazer]

I much prefer XML for most of my config files since it is easy to work with, transport, has many good libraries and tools built for it and is very popular so most people will be familiar with it.

Though for a few of my projects JSON worked better and gave more flexibility/easy of use then XML and I had fun working with it.

As for parsers I am not to familiar with JSON so I won't comment on that but for XML I highly prefer TinyXML2 since it is very lightweight, great memory allocation and speed and personally I prefer that it doesn't have a requirement of STL like tinyxml.

I think it really all comes down to what the person feels most familiar with and what suits the project best.

[chrisname]

JSON is the best. It's almost as intuitive for non-programmers who want to edit configuration files by hand as INI is, much more than XML, but it has all the expressiveness and robustness and flexibility that XML has and INI lacks. I still tend to use INI, though, because writing a basic INI parser is so trivial.

[3hM2Nwbp]

I use all three (exclusively because boost::property_tree provides excellent parsers for them). Changing user-code to use a different format is a one-liner if boost::property_tree is used. Oh, and it's header-only, so that's always a plus.

http://www.boost.org/doc/libs/1_55_0/doc/html/property_tree.html

* Code

#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/ini_parser.hpp>
#include <boost/property_tree/json_parser.hpp>
#include <boost/property_tree/xml_parser.hpp>
int main()
{
	using namespace boost::property_tree;
	
	ptree tree;
	
	// Pick your poison
	xml_parser::read_xml("file.xml", tree);
	ini_parser::read_ini("file.ini", tree);
	json_parser::read_json("file.json", tree);
	
	for(auto child : tree.get_child("some_collection"))
	{
		// Mutate children, perhaps.
	}
	tree.put("metadata.modified", true);

	// More poison
	xml_parser::write_xml("file.xml", tree);
	ini_parser::write_ini("file.ini", tree);
	json_parser::write_json("file.json", tree);
}

[chrisname]

Luc Lieber wrote:

it's header-only, so that's always a plus.

Not always -- recompiling all those templates can be very time-consuming.

What is the difference between Boost.Property_tree and Boost.Program_options? Would you say property_tree makes program_options obsolete?

[Zhuge]

Property_tree is (more or less) for parsing files into a tree structure, while program_options is for parsing command line arguments. The configuration files used by program_options are relatively simple compared to what is allowed with a format like XML, etc., but again are mainly to serve the more simple purpose of configuring command line arguments to a program, not for any arbitrary structure of data.

So while you could use property_tree to parse a configuration file, I wouldn't say it can replace program_options for handling all configuration since command line arguments require a different approach.

[chrisname]

Thanks Zhuge. Is there an easier way to integrate them (allowing, e.g., your command-line to override your configuration file) than, for example, writing a class that inherits boost::property_tree::ptree as well as boost::program_options::variables_map and integrates the data?

[Zhuge]

My experience with program_options is actually very limited; I've never had occasion to use it for anything more than cases on the level of the basic tutorial.

I assume you are reading in the configuration file into a ptree, but want program_option's information to take precedence over whatever you get from processing the ptree?

In that case, perhaps you could read in the configuration file, process the ptree to set up initial values for your configuration, then have program_options overwrite those values as applicable.

Apologies if this isn't very helpful. :/

[Stewbond]

Anyone have experience with QJSON?