RE: [boost] Re: Preliminary submission: command line & config fil e library

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2003-01-17 12:06:52

> As my example above shows, you can use simple syntax for two 
> arguments and 
> explicit/named for all others. Take a look at Boost.Graph: it 
> uses named 
> arguments, but mostly for numerous details such as 
> "color_map". You don't have 
> to write
> 
>     transitive_closure(graph_param(g));

Unfortunately I am not familiar with Boost.Graph, but I believe that in
specific case of CLA I would prefer one style for all parameter's modifiers.
I do not see how description is more important that optional/required for
example. Looking on your example I already confused:
>     desc3.add_options()
>             ("output,o", "file", "where to send output")
>             ("magic", "value", "magic value for the program")
>                 .default_value("43")

What is "file", "value"? Why do I need to supply default value as a string
and not 43 itself?
What is ,o? Do I need to remember everything that you will reply?

>     options_description desc;
>     desc.add_options()
>     ("roll_trace_file?", "arg?", "roll trace file)
>     ;

What id "arg" then? Keyword? Would you remember difference between first
question mark and second?

> >>And what those operator<< will do?
> > Feed option definitions to the cla::parser.
> 
> Eeh.. that's only possible if program_options, 
> config::parser, and cla::parser
> have the same interface for declaring options. If you add 
> custom modifier to
> cla::parser, you have to add it to program_options, and the 
> to config::parser
> and then to registry::parser, if you have it.

Not at all. program_option may support only common superset on all
configuration components features. It does not need to know about all
supported features of all components. In my understanding program_options is
only helper facility for one very useful case.

> 
> - Volodya

Gennadiy.