From: Boris (boriss_at_[hidden])
Date: 2006-04-21 12:49:22
Vladimir Prus wrote:
> 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.
I haven't used program_options yet. But if I understand correctly both
libraries seem to support storing and accessing data with strings that might
describe some kind of hierarchy. This seems to be the core idea of both
libraries - is this correct?
Then it wouldn't matter much what container is used. However a generic tree
which can store data hierarchically probably makes most sense. If I
understand correctly both libraries could make use of such a class?
While a generic tree could store any data we would still need something to
read data from a XML file, a INI file, the Windows registry, program options
etc. to populate a generic tree. How about a hierarchical iterator? Just
like stream iterators they could be coupled with a data source. Source code
would look somewhat like this:
ihierarchical_options_iterator<string>(argv + argc), inserter(t));
This should be flexible, extensible and based on existing practices?