why are GOTO's not used ...

[raashid bhatt]

why are GOTO's not used they just a simple JMP instructions what's bad
about them

 

[Nick Keighley]

On Sun, 17 Aug 2008 10:28:23 -0700 (PDT), raashid bhatt


A fundamental problem with the goto contstruct is that it has no
API.

?? eh?

Consider how function calls work. In C a function will
have a prototype that specifies the number of arguments, their
types, and the type of object that the function returns. A
function's prototype is its API.

A nice thing about functions is that interaction between the data
inside the function and the data in the caller is restricted to
the API. That is, functions are decoupled from their callers
except through the API.

This is not true of the goto construct. Since it has no API, the
code in the target of the goto gets its data from the scope
containing both the goto and its target.

most C constructs don't have an "API". Though I am unclear what
an "API" is. I know API stands for Application Programming
Interface, but you don't seem to be using it like that.

 

[Kenny McCormack]

?? eh?

He's using the term in a more general sense than is common.

He means "like a contract" - i.e., the API is a contract between the
user and the implemntor - that says "I do this. And you will do this.",
with an implicit understanding that nothing else will happen. I.e., the
contract lists everything that will happen, and includes by extension a
prohibition on anything else happening.

Well defined functions, that don't use global variables, obey this
convention. Things like global variables and GOTOs break the convention.

 

[John Bode]

why are GOTO's not used they just a simple JMP instructions what's bad
about them

It doesn't matter how fast your code is if it can't be understood or
maintained, and
undisciplined use of the goto statement can lead to code that is
difficult understand, debug, and maintain.

It makes it harder to debug code by inspection. Take the following
code fragment:

...
i = 0;
label: i++;
printf("%d\n", i);
...

What value gets printed for i? Does i ever get initialized to 0?
Until you account for every instance of "goto label" in the function,
you don't know. If the author of the code was sane and the functions
are reasonably small, it's not so bad. As the size of the function
increases, however, it can get harder to trace. The problem gets a
*lot* harder with multiple gotos:

...
i = 0;
label0: i++;
label1: printf("%d\n", i);
...

Now what gets printed? You have to account for every instance of
"goto label0" *and* "goto label1".

I get to repeat the story everyone else here has heard a thousand
times. A group I was in was tasked with speeding up some code that
controlled a 3-d graphical display. It was originally written by some
wirehead who essentially wrote a BASIC program with C syntax. Instead
of breaking the code out into separate functions, he put *everything*
in main() (roughly 5000 lines of code) and used about 15 gotos,
branching both forward and backward, to simulate subroutines.

It took a co-worker roughly 2 weeks to figure out the actual flow of
control in the program. Worse, once we figured out how it worked, we
found we couldn't actually make any changes to speed it up; the code
was *so* brittle that any change rendered it useless.

By themselves the goto statements weren't the problem (the BASIC
programming philosophy and an unfamiliarity with C were the big
problems), but they made the problem a *lot* worse.

There *are* times when it does make sense to use a goto, but they are
few and far between. About the only time I've used them
professionally was to break out of a deeply nested loop:

for (i = 0; i < N; i++)
{
for (j = 0; j < M; j++)
{
for (k = 0; k < L; k++)
{
/* do something interesting */
if (error)
goto error1;
}
}
}
...
error1: /* handle error */

Bode's rules for using goto:

1. Never replace a standard control structure with a goto;
2. Branch forward only - do not use a goto to branch backward in the
code;
3. Never bypass the entry point of a control structure (i.e., never
branch into a loop or if-then-else block);