On Sun, 11 May 2008 20:01:34 +0200, Eligiusz Narutowicz wrote:
> Harald van Dijk <truedfx@[EMAIL PROTECTED]
> writes:
>> On Sun, 11 May 2008 09:10:07 -0700, Tomás Ó hÉilidhe wrote:
>>> On May 11, 2:29 pm, Chris H <ch...@[EMAIL PROTECTED]
> wrote:
>>>> >If anything I would imagine
>>>> >it makes the implementation more complex if one tries to enforce a
>>>> >specific order between char and unsigned.
>>>>
>>>> I would have thought if tokens are always in a set order it is easier
>>>> to parse.
>>>
>>>
>>> Imagine you're writing a program that has commandline options, e.g.:
>>>
>>> prog.exe -t -e -f
>>>
>>> Now imagine the code you'd have in main for it. You might have some
>>> sort of switch statement to check whether the command line option is
>>> 't' or 'e'. If you were to impose a strict order on the commadline
>>> options, then you'd have to keep some sort of list of what previous
>>> command line options appeared and in what order. Sounds like a useless
>>> and inefficient restriction to me.
>>
>> This is simpler than allowing options to appear in any order.
>>
>> if (streq(*argv, "-t")) {
>> opt_t = true;
>> argv++;
>> }
>>
>> if (streq(*argv, "-e")) {
>> opt_e = true;
>> argv++;
>> }
>>
>> if (streq(*argv, "-f")) {
>> opt_f = true;
>> argv++;
>> }
>
> I do not see how that is any simpler that a for loop with switch where
> there is only one argv++.
True, you could easily convert it to
for (;;) {
if (streq(*argv, "-t")) {
opt_t = true;
argv++;
} else if (streq(*argv, "-e")) {
opt_e = true;
argv++;
} else if (streq(*argv, "-f")) {
opt_f = true;
argv++;
} else
break;
}
and change that to use switch or whatever method you want, but if you do
this, you no longer guard against -t -t, which was an error when the order
was forced, but would be silently accepted here. To fix that (assuming you
don't want to allow it -- with the original case of unsigned char, you
wouldn't) you need to add extra checks. This isn't difficult, but slightly
less simple than having a fixed order.
|
