The biggest difference is that property_tree is a DOM, not a linear structure.
In a big part it's implementation detail. I might as well keep all the parameter in single list with names like "a.b.c.d". Though I agree that variable_map could be done better.
No, this is not implementation detail. This is a fundamental difference. Of course, you can have PO store options in form of a.b.c.d, but that does not make it hierarchical. How do you make a copy of a branch and attach it somewhere else? How do you remove a branch? How do you take only one branch and make another options structure of it? All these operations would be extremely cumbersome, not to say that also possibly inefficient, using linear structure.
[...] With program options you would have to teach my_component extract values from whatever place they are in config file(s).
Other things that are not supported by program_options:
- writing configuration
Why would I need that? Or rather in how many instances I would need that?
I think this type of usage is rather common, at least the way I used property tree relied heavily on these features. For example I used it as a primitive serialization library where files containing objects were human creatable. I had an application which had GUI to manipulate these objects, and allowed to save them back again to files. All I/O was done using property tree.
- XML, JSON, INI, Windows registry parsing out of the box
You could implement them as an add-ons.
How can you present hierarchical structure like XML or JSON as a linear string of options? A string of a.b.c.d -form keys is not extremely useful.
Also, I think that in simple cases, syntax offered by property_tree is simpler and has less steep learning curve. It's matter of opinion and again it's just PO issue.
Possibly, but it also supports options descriptions and notifications. These do not belong to property_tree. For example descriptions would make little sense when parsing XML file.
Essentially it's unusable for anything any different for one rigid format you chose.
That format covers most simple command-lines I have seen. It is not enough to implement a command line for a tool like gcc, but then it is not intended to. If you are implementing a copy utility that takes two filenames and several flags, (like -r, -m etc.), it works.
9. Access interface are lacking. If I got string identify subsystem and string that identify parameter separately why do I need to concatenate them to get to the value
You don't have to concatenate them:
int subsystem_parameter = pt.get_child("subsystem").get<int>("parameter");
And if I have more levels?
string trace_config = pt.get_child("MyLib").get("debug").get("trace").get("config");
I would rather prefer
string trace_config = pt.get("MyLib", "debug", "trace", "config" );
This is a matter of taste, in my opinion both are similar. But would you implement your version using variadic arguments or by supplying implementations up to N parameters?
I don't see a way I could simplify it considerably. If you see, please let me know how. I did. See config_file.hpp ib Boost.Test code base.
I'll definitely have a look. Best regards, Marcin