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

Llew Sion Goodstadt wrote:

...

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... Surely this would not be greatly affected by something like:

class typed_value ... { public: std::string arg_name; typed_value* arg_name(const std::string& arg_name_)

I'm concerned that the typed_value class becomes a big bag of data and methods, and it's hard to understand it by just looking. I think I'll need to drop all those 'implicit'/'multitoken'/'zero_tokens' method in favour of 'min/max' scheme used by positional_options, but I would not like to do this right before release. - Volodya

Hi Jonathan,

I was asking for something like: value<type>(&variable)->default_value(default,"displayed version of default","displayed version of argument type") which would give -option: displayed version of argument type (=displayed version of default)

Although, ->type_text("displayed version of argument type")->default_value(default)->default_text("displayed version of default")

might be considered more legible. I prefer the existing positional arguments overload (the meaning should be obvious from context as well as library documentation, and remember, you'll be typing many of these options)

There's another possibility: value<type>(&variable, "filename")->...... something like that was in the pre-review version, with the difference that the value name was also used to specify flags, e.g "filename?" would mean the value is optional. I'll add it to my todo. I techically could add this feature right now, but I'd like all non-critical changes to have some "soak time" because adding to CVS.

Also, I'm not sure why 0-argument items couldn't appear in a config file. I declare the number of arguments used by options before I parse the config file, after all.

Because the current config parser, systantically, requires that everything specified there has a value. If you specify that an option accepts no explicit value, it can't be present in config file. - Volodya