|
Boost : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-04-20 16:51:27
> Hi Everybody,
>
> I see there is some confusion about possible overlap of program_options
> library and property_tree libraries. I will try to present my view on the
> problem here.
>
> First of all, my opinion is there is very little overlap. The biggest
> difference between the libraries is that property_tree is hierarchical and
> program_options is linear - i.e. options are accessible through a map-like
> interface.
> Structure of file formats, like XML, JSON etc. is inherently hierarchical.
> The presence of hierarchy is their greatest strength, and most important
> feature. Large amount of information is conveyed by structure of the tree
> alone, not only by values of options it contains. One option in two
> different branches of the tree can have completely different meaning.
> Contrary to that, in program_options library there is only at best a
> notion of "positional options" which is completely different from
> hierarchy.
> Briefly, PO library operates on a flat strings of options, property_tree
> is a DOM.
IMO it's just one of the many design flaws of PO library.
> Think of property_tree like a replacement for Microsoft XML parser, or
> JSON API, or Windows INI API, or registry API. Do you imagine using
> program_options to XML trees, like you get from XML parser? It is not
> suited for that, its problem domain lies in completely different place,
> namely parsing a linear string of (command-line) options, possibly
> supplied as a config file or files.
>
> In addition to that, PO library does not support writing the structures
> back to config files. It is not a flaw with the library, it just does not
> need to do it, because options for programs are meant to be "one shot", or
> "read and forget", like command line arguments. There's not need to store
> them back where they came from.
>
> On the other hand, PO library supports many things that do not belong to
> property_tree. These include, for example, options descriptions and
> notify() mechanisms.
>
> Taking all that into account I do not see why anybody insists there might
> exist 1:1 correspondence between the libraries. I agree both can parse
> command lines, but that's about it. Other functionality is very different.
I admit I must've misinterpret the problem domain you are trying to cover.
So now you are saying that your library should be used to implement
permanent data storage? But we already have a solution for that either.
Much better IMO in any sense (safety, convenience, automation etc). All in
all in between PO an Serialization library I do not see any place for this
submission. It's doesn't stand a comparison as runtime parameters support
facility even with PO library ( no conflict resolution, no formats
specification, no automatic/custom validation no async action assignment
etc). And it's doesn't stand a comparison as a permanent storage facility
with Serialization library (in most senses). Make no mistake these are two
different domains. And you could not sit on two chairs. Especially if any
one of them is too big for you.
Gennadiy.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk