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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-20 04:05:23

Rozental, Gennadiy wrote:
>>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?

You still need to remember something. For example, your library uses ","
to separate elements of std::list<...> parameter. Can I guess that from the 
options declaration? Can I guess what "multiplicable" is?

The non 100% obvious notation in the above example is ",o" for short option 
and naming the value for option.

With yout proposal it would look something like

parser << named_parameter<>("output") << short_name<>("o") << 
value_name("file") << description("where to send output")

And it should be repeated for each option.

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

I don't see much problems. "arg?" is "parameter_name", as documentation says.
If you hack on command line parsing right now, it's easy to remember the
syntax convention. Few month later, you'd at most have to briefly look
at docs.

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

What's "common superset"? Assuming you meant "common subset".

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

Does key_lookup_policy support short options? No. Therefore program_options 
cannot support them either. So, if I want to handle both command line
and config file I have to give up something very handy.

- Volodya