Boost logo

Boost :

From: Neal D. Becker (ndbecker2_at_[hidden])
Date: 2004-05-07 06:32:44

Vladimir Prus wrote:

> Neal D. Becker wrote:
>> It's a small point, but here's my opinion.  You say something like: "If
>> option requires a value and  following -<number> doesn't match an option,
>> then parse it as an argument".
>> I would suggest "If option requires a value then parse *any* following
>> string, including -<number> as a value, unconditionally".
> So the different would be that
> -a -b
> where both "a" and "b" are allowed option and "-a" requires a value,
> will be reported as invalid value of option "-a" not as missing value on
> the command line? Why do you think that's better?

There are 2 choices:

1) Don't correctly parse some correct cases


2) Give confusing error message for incorrect case.

You'll agree #2 is better than #1.


-a -3

where -3 is a valid option, and -a takes a value.

I suppose if you decide it's better to parse -3 as an option, then you do
have a workaround:


I'm not sure what gnu getopt does in this case (although it seems to always
do the right thing (TM), because I'm sure I've used this and never noticed
a problem).

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