Boost logo

Boost :

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-04-20 17:02:56

"Marcin Kalicinski" <kalita_at_[hidden]> wrote in message
>>> 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,

You got me convinced. PO indeed shoudld be implemented differently ;)

> not to say that also possibly inefficient, using linear structure.

Who cares?

>>> [...]
>>> 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.

This type of usage require different tools. I would use Serialization lib
for that.

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

They would make a lot of sence. Especially when you will start producing an
error message if some required property is missing.

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

Exactly. It does not stand a comparison with another existing solution for
CLA parsing..


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