Hi Jonathan,
Now this is better:
bool help_flag; options.add_options() ("help,h", bool_switch(&help_flag),"produce help message");
I tried it, and it works, but the usage string is a little odd:
-h [ --help ] arg (=0) : produce help message -v [ --version ] arg (=0) : print the version number
Apologies for self-reply:
It turns out that the "optional" nature of the argument to a bool_switch creates an impossible situation when positional arguments are used. For instance:
myprogram -h positional_argument
will try to parse positional_argument as a bool if I use a bool_switch for the -h option
This seems like fairly useless behavior; bool_switch should *never* expect any argument (or, I should say, I'd like a version that doesn't consume my positional parameters).
I've changed bool_switch so that it does not accept any arguments. This also solves the problem with "arg (=0)" output. There's one possible problem. For command line, we most likely don't want explicit value for bools. But in config file, the value is always present. This is the only case I know where single options description for command line and other sources is problematic -- if you describe an option with bool_switch, it can't be specified in config file. Let's see if that's a problem.
Also, in parsers.cpp,
throw too_many_positional_options_error( "too much positional options");
should be "too many positional options".
Thanks, fixed.
Similarly, is there some easy to use hook for customizing the "arg" to indicate the type of the data (similar to how the textual representation of the default argument can be changed, e.g. value<Infile>(&forests_file)->default_value(default_in,"STDIN"), so that I could get something like: "-f filename (=STDIN) :" instead of "-f arg (=STDIN) :"?
No, it's not possible at the moment. Since its not a showstopper, I'd like to take some time to think about it. The typed_value class is getting too big... - Volodya