> 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?
It has almost nothing to do with parameter definition. It's details of
argument parsing format. You may though specify it explicitly by naming the
interpreter for your parameter, like this:
cla::named_parameter<std::list<..>, space_separated_list>
> Can I guess what "multiplicable" is?
I think it's pretty obvious. If not I may change name to more
expressive/clear if you know one.
> With your 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.
in fact:
parser
<< dual_named_parameter<>( "output", "o" )
<< format_descr( "file" )
<< description( "where to send output" );
In your case:
desc3.add_options()
("output,o", "file", "where to send output")
The only differences are is that I explicitly specify what does these
strings mean and I allow different kinds of parameters (positional for
example).
> Does key_lookup_policy support short options? No.
But dual_lookup_policy does. program_options may use this policy. I
personally prefer to use key_lookup_policy with guessing_key_policy. I do
not need to remember 2 independent names and could specify long or short
name.
> 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.
That is not correct as it follows from above.
>
>
> - Volodya
Gennadiy.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
