Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at