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

[Vladimir Prus]

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost