Boost logo

Boost :

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
>> 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,

Boost list run by bdawes at, gregod at, cpdaniel at, john at