From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-20 15:56:17
>> The biggest difference is that property_tree is a DOM, not a linear
> 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
>> 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
>> - 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 =
> And if I have more levels?
> string trace_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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk