On May 11, 8:18 pm, Eligiusz Narutowicz<eligiuszdotn...@[EMAIL PROTECTED]
>
wrote:
> Harald van D=C4=B3k <true...@[EMAIL PROTECTED]
> writes:
>
>
>
> > On Sun, 11 May 2008 20:01:34 +0200, Eligiusz Narutowicz wrote:
> >> Harald van D=C4=B3k <true...@[EMAIL PROTECTED]
> writes:
> >>> On Sun, 11 May 2008 09:10:07 -0700, Tom=C3=A1s =C3=93 h=C3=89ilidhe
wr=
ote:
> >>>> 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
easie=
r
> >>>>> 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
useles=
s
> >>>> and inefficient restriction to me.
>
> >>> This is simpler than allowing options to appear in any order.
>
> >>> if (streq(*argv, "-t")) {
> >>> opt_t =3D true;
> >>> argv++;
> >>> }
>
> >>> if (streq(*argv, "-e")) {
> >>> opt_e =3D true;
> >>> argv++;
> >>> }
>
> >>> if (streq(*argv, "-f")) {
> >>> opt_f =3D 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 =3D true;
> > argv++;
> > } else if (streq(*argv, "-e")) {
> > opt_e =3D true;
> > argv++;
> > } else if (streq(*argv, "-f")) {
> > opt_f =3D true;
> > argv++;
> > } else
> > break;
> > }
>
> No. You would take out the argv++ into the for loop.
>
>
>
> > 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
ord=
er
> > was forced, but would be silently accepted here. To fix that (assuming
y=
ou
> > 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
slight=
ly
> > less simple than having a fixed order.
>
> No it isn't. I do not understand what you mean by -t -t being a problem
> and how using if statements one after the other solves this. Last
> occurrence rules.
The point is that in C syntax
"unsigned char unsigned" is not allowed. So
the analogous situation with option processing
would be that you wouldn't want to allow for
example "-t -e -t".
|
