Re: [boost] Re: program options change request

From: Neal D. Becker (nbecker_at_[hidden])
Date: 2003-06-06 09:22:07

On Friday 06 June 2003 10:10 am, Vladimir Prus wrote:
> Neal D. Becker wrote:
> > Currently (last I tested) program options when used with variable map
> > will set bool options to false even though they were not specified on the
> > command
> > line.  What I'd prefer is that all options be left alone unless they are
> > set
> > on the command line.  I've been bitten by this unexpected behaviour.  (I
> > set bool option = true, then use
> >
> > parse_command_line(argc, argv, desc);
> >     variables_map vm;
> >     store(opts, vm, desc);
> >
> > And my bool option winds up set false even though nothing was specified
> > on the command line.
>
> Yes, that's true. All bool options implicitly have default value of
> "false". In fact, I think this is quite reasonable. Unless some switch is
> on, it's off. This saves the user the need to check if option is present.
>
> Could you describe how this behaviour has bitten you? There's probably a
> solution already.
>

I thought I did describe it.  I converted some code which was using a 
different library (getopt or popt).  Before calling the option parser, I set

bool someopt = true;

After the parser the option is set false.  I didn't expect this behavior.  
This doesn't happen with other libraries, such as popt.  Furthermore, and 
perhaps more important, the treatment of bool is different than any other 
options.  This inconsistency is bound to trip up other users beside myself.

I can appreciate the usefulness of the current behavior, and I also know that 
there is a workaround (.default_value("true")), but this only works if you 
notice the unexpected behaviour!

The only good solution I can see is to either make the bool behaviour 
configurable, or somehow force the user to choose so he will notice.