Re: regarding "goto" in C

websnarf@xxxxxxxxx wrote:

> I personally follow only one rule regarding goto: avoid using it unless
> using it leads to either clearer code or faster (executing) code. This
> rule alone is sufficient to make the use of goto fairly uncommon in my
> code to the point of "spaghetti code" never being an issue. (If
> there's one exception it would have to be parsers -- but in those cases
> even the cleanest control structures don't actually lead to a clearer
> representation of the parser.)

I've never had to use a goto in a parser; could you unpack the reasons
why you've wanted one? [email if it's likely to be wildly off-topic.]

--
Chris "believes seventeen improbable things before coffee" Dollin
Seventeen, forty-two - what else is there?
.

Relevant Pages

  • Re: regarding "goto" in C
    ... using it leads to either clearer code or faster code. ... This rule alone is sufficient to make the use of goto fairly uncommon in my code to the point of "spaghetti code" never being an issue. ... (If there's one exception it would have to be parsers -- but in those cases even the cleanest control structures don't actually lead to a clearer representation of the parser.) ...
    (comp.lang.c)
  • Re: regarding "goto" in C
    ... >> I personally follow only one rule regarding goto: ... >> using it leads to either clearer code or faster code. ... > I've never had to use a goto in a parser; ... then an indirect branch) which you pay for in the "well ...
    (comp.lang.c)
  • Re: Iterate before loop end
    ... >> I did consider GoTo, just for a moment, but you know what that leads ... >Yeah, in this instance, an optimal solution...no overhead of extra ...
    (microsoft.public.vb.general.discussion)
  • Re: regarding "goto" in C
    ... >>> rule alone is sufficient to make the use of goto fairly uncommon in my ... >> I've never had to use a goto in a parser; ... > I've seen is a switch statement wrapped in a while, ... continue <expr>; ...
    (comp.lang.c)
  • Re: Iterate before loop end
    ... > I did consider GoTo, just for a moment, but you know what that leads ... Yeah, in this instance, an optimal solution...no overhead of extra ...
    (microsoft.public.vb.general.discussion)