Neal,
>> 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.
I see. You didn't mention you was moving from another library.
> 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.
Good argument.
> 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.
I think the latter is possible. I can make behaviour of 'parameter' function
the same for all types, and introduce another function, say 'switch' for
current ('false' as default value) behaviour. You'd have to write
desc.add_options()
("unified", switch("arg", &b), "unified format");
;
does this make sense?
- Volodya
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
