> 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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
