[boost] Re: program_options bool_switch usage string

From: Jonathan Graehl (jonathan_at_[hidden])
Date: 2004-09-17 13:37:05

>
>
> A newer parser could recognize the end of an option name first, then
>> interrogate the option to see if it takes an argument, then if it does,
>> expect to parse a "= value".
>
>Hmm... that would mean that you can specify a value in config file for an
>option which does not allow a value?
>
>E.g.
>
>    ("foo", bool_switch()....
>
>and then in config file:
>
>    foo=false
>
>then "false" will be just ignored? OTOH, it might be reasonable to decide
>that the desired number of tokens applies only to command line, since other
>sources don't have any parsing ambiguities. 
>

Actually, I was suggesting that a value for an option that doesn't 
accept one, would be a parse error.  Otherwise you have possible 
confusion with user thinking it's a value<bool> and by saying foo=false, 
you mean the same thing as not specifying the "foo" switch.

What's the use of an option with an OPTIONAL value? :)  Wouldn't you 
just omit the option and use the default value if you didn't want to 
provide one?  It should be possible to specify options, at command line 
or in config file, that have no value; their presence or absence (often, 
commented or uncommented in standard practice) would determine the value.

I mean, a config file could have:

value_opt=23
bool_switch_opt
...

(not bool_switch_opt=something)

It would be perfectly pleasing to me though, to allow bool_switch to 
have a true or false value in a config file, and not at the command 
line.  However, that would violate the existing design, wouldn't it?