Re: [boost] Preliminary submission: command line & config file li brary

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-16 04:34:12

Rozental, Gennadiy wrote:
> Now about config file feature.
> 
> I have 2 major issues with your design.
> 
> 1. You again placed 2 eggs into same basket.
>    There are 2 levels of configuration file reading
>     a) level that is responsible for comments lines, empty lines, continued
> lines, include, ifdef, defines and so on
>     b) level that is responsible for variable definition in configuration
> file

I disagree. The program options library has one core class for desribing 
options -- options_description. It's not coupled to any parser. The 
config_file is a parser for concrete format. It really has the 'add_option'
method, but it's there to make the class complete.

There's real posibility that people would say: I want *only* to parse config 
file, I don't want any large dependencies. They can you config_file directly.

The parameter validation facilities in config_file are really minimal. While
it would be possible to separate those facilities, I don't know what it will 
give you. Any nontrivial usage requires options_description already, and 
that's competely because. The "minimal" usage will be more complicated.

> 
> One may want to use only first level and it's configuration is supplied as
> XML

This parses ambiguously for me. To you mean that the configuration of the 
first level is given in XML? Or that first level parses configuration data in 
XML? Assuming the latter, I don't see any problem. You'd have

    options_and_arguments
    parse_xml_config_file(std::istream&,
                          const options_description& desc);

Everything is described in 'desc' and the implementation of the function,
can use it in anyway it likes. For example, by obtaining all options from XML 
tree and checking if they are allowed.

> 
> 2. Look closely on config_file interface:
>     operator++,
>     operator bool
> 
> Does not it look like something familiar? 
> I have a solution based in iterator_adaptor that present iterator interface:
> config_file_iterator that manage level a) of configuration reading. It's
> very flexible and allows you to configure almost every part of it's logic.
> For example comment char, line continuation char and so on.

I'm not able to comment in detail without seeing the code. However,
whether it's iterator or not is not much import, IMO. The basic usage
I'm envisioning does not require to even explicitly create config_file
instance!

And what the flexibility for? Every config files I've see use the same
format. Everybody know that format. If your code allows to treat "\" as 
comment character and "#" as continuation character, what advantages does it 
give. In short: do you have a concrete example where this flexibility is used?

> I also have a solution that works based on config_file_iterator -
> parameter_handling. It allows to access multi level (with namespaces and sub
> namespaces) parameters defined in config file.

And this solution is not compatible with the command line handling, right?

- Volodya