Re: [boost] Do really property_tree and program_options overlap?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-04-21 03:03:01

Marcin Kalicinski wrote:

> Briefly, PO library operates on a flat strings of options, property_tree
> is a DOM. 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 manipulate XML trees, like the ones 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.

Well, this is generally wrong. The program_options goal is to obtain named
runtime options from whatever source you can store them. I hope to add
Win32 Registry or LDAP support in future. Note also that options *are*
hierarchical, you can use "your_app.window1.button15.width" as option name,
if you're so inclined.

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

This *is* a flaw with the library, and this will hopefully be fixed.

> 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 don't know how suggested 1:1 correspondence, but it's crucial for both
library to work together in a sane fashion. Let me describe the primary use
case.

At the moment, boost::program_options is well suited for reading simple
values from command line and config files. In future, it will also be able
to write config files and read/write other config sources (again, LDAP
comes to mind).

However, the hierarchical naming of options is not scalable. Right at the
moment, I'm working on debugger component of an IDE, and there's breakpoint
window. It has a number of breakpoints, and each breakpoint has a bunch of
other data. Narually, the state of the window should be saved in a config
file. It's technically possible to write it using option names like:

   kdevelop.debugger.breakpoints.breakpoint1.tracing.expression1=i

but generating such structure is pretty cumbersome, because there's no
interface to work with hierarchical options. DOM (or property_tree!) is
such an interface. To put it other way, I think it would be worthwhile to
either:
  - replace the variables_map class from program_options with property_tree
  - make variables_map::operator[] return property_tree

Of course, both solution require that property_tree make it possible to:

  - Access any node with a fully-qualifed name
  - Allow to store values of any type as nodes.

The first requirement is already met. The second seems not -- the
property_tree docs say that operator>> is used by the 'get' methods, while
program_options used strong typing. I would say the second requirements is
hard one for program_options, so would hope property_tree is adjusted to
make this possible.

 
> One has to distinguish between reading command-line options (or other
> simple configuration) and reading structured DOM data. For example, take a
> program like visual XML editor. It could use both PO and property_tree to
> read its startup config (keyboard shortcuts, font etc.). But only
> property_tree would be suitable to handle XML files to be parsed,
> displayed, edited and saved by the editor. It would be rather ridiculous
> to use program_options to do that, although not impossible, if one tried
> really hard.

The question is where to draw the line. Reading XML with program_options is
not what I'd like to do. Ideally, if somebody wants XML config files he
should do this:

   options_description desc.........;
   property_tree options;
   store(options, parse_command_line(desc, .....));
   store(options, property_tree::parse_xml_config_file(.....));

So, parsing of XML files is done by property_tree, and merging that data
with command line options is done by program_options.

I think it's much more reasonable to use program_options for parsing command
line, and classic config files. I'm not sure about registry values.

- Volodya