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

or

2) Give confusing error message for incorrect case.

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

So:

-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:

-a=-3

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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk