As long as JSON has a hierarchical structure, wouldn't it be better for you to use the future property_tree library?
To which Boost library does property_tree belong? Is it Boost Property Map? I found a file propert_tree_rev5.zip in the Vault but it has been uploaded two years ago?
It will be a library on its own. I'm not really aware of the whole story but basically it has been started some time ago and after having been in standby mode during a while, it has restarted recently: http://www.nabble.com/Status-of-the-Boost.Property_tree-library-td15977780.h...
That's a good question. I actually wondered about using hierarchical storage for program_option, possibly based on property_tree. Nothing concrete at this point.
Yes, that's what I meant. Even if I can create my own parse function it won't help me if the file format I parse can't be represented by the storage used by Boost.ProgramOptions. But I guess the storage can't be as much generalized that someone who wants to use any file format X can create a parser for Boost.ProgramOptions, too.
Indeed, a few glue code between program_options and property_tree library would be a very neat solution, I completely agree with this idea. Let's keep it in mind until property_tree is released. For the storage problem, why not merely insert some dots into the variable names without changing anything to the storage model itself: you would query variables["object.subobject.field"] to access a nested field. Bruno