Personally, i use Lua for config files. Since i use it for scripting anyway, i don't see a reason why i wouldn't also use it for configuration.

I found TinyXML much easier to set up. It was ready to go in 20 minutes. Can't same the same thing about jsoncpp because I still haven't figured out how to get necessary header and source files.

Using CMake is really confusing. Will the header and source files copied from jsoncpp-master (raw zip file from github) work?

Are you using visual studio? There's a makefile you can use to build it under makefiles/msvc2010 (and one for vs71 too). Otherwise, you can use python to make the amalgamated build (read the docs), but you need python 2.6+ at least.

Good luck!

Yes, I am using visual studio. Just managed to build jsoncpp properly. I had to change some code generations settings and it built just fine. Now the only thing I need is to find the documentation or tutorials. Any tips where to search?

The wiki on github has some documentation, and the old project page has doxygen documentation

Looks like there is some documentation in the docs folder too from the zipped source.

FWIW, I used to use XML before I found out about JSON, but JSON is so easy and non-verbose, while xml can be a pain in the butt.

I also had switched to JSON back when I did a lot of Web work, since that was the hot thing that everyone said you had to use or were dumb, but since working on games I've switched back to XML. XML still has a number of small advantages including a better set of mature editors and RelaxNG/schema support.

Most importantly, though, XML is much easier to merge safely when pulling from a source repo than JSON. This is because JSON has the mandatory trailing commas in arrays/objects on every entry but the last; this makes each item have a slightly different line format depending on where it is in the container. XML items in a container are all uniformly formatted. Non-uniformity means that merging changes from two different sources that both added lines requires attention to the format and no automatic merges, which is terribad for content folks and usually just a pain in the rump for engineers.

This is primary for content files that will have their own editor and aren't end-user facing.

For user-facing configuration files, the good ol' INI format still wins. It's significantly easier to use than JSON, is still mergable if you check-in default files or the like, and also has drop-in parsers to use like https://code.google.com/p/inih/.