1

Possible Duplicate:
Examples of good gotos in C or C++

What uses of the goto statement do you consider acceptable? I am discussing some coding guidelines for C embedded work, and wondering if there are cases where goto is the cleanest way to do things.

Community
  • 1
  • 1
Steve Hanov
  • 11,316
  • 16
  • 62
  • 69
  • 1
    an interesting read on this subject is [Structured programming with go to Statements](http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf), by D. Knuth. It was written in 1974, but still contains interesting examples and thoughts – tonio Jun 03 '10 at 16:20

3 Answers3

1

For C, I find it useful to use goto for a common exit point in some functions. If you need to release resources before returning, it's nice to do retval = -ERROR; goto fn_exit; instead of trying to break out of multiple layers of for/while loops.

Some would argue that it isn't necessary in well designed code -- when you reach a point where using goto is attractive, you should be breaking the function up into multiple sub-functions. Maybe that's true in some cases, but if you have to pass multiple variables in, or pass pointers to variables so a sub-function can update those values, I feel like you've added unnecessary complications.

Here's a recent SO question on using goto for error management. I'm sure that browsing the goto tag will get you even more answers.

Community
  • 1
  • 1
tomlogic
  • 11,489
  • 3
  • 33
  • 59
0

I found that there are quite a few places where goto might simplify the logic. My rule is that no 2 goto's overlap each other and that the goto and its label are 'close'; usually, no more than 30 lines apart.

Usually, when I have a complex condition that I have to check many things, a goto might help:

if ( condition1 && cond2 )
  if ( checkFile( file ) )
    goto DONE;
else
  if ( condition3 )
    goto DONE;

handleError();
return 0;

DONE:
...do something...
return 1;
Gianni
  • 4,300
  • 18
  • 24
  • I can think of more elegant solutions *without* goto, so this is not a strong argument. For example creating a function `int done()`, and replacing `goto DONE` with `return done()`. There is almost always a better way than to resort to goto. – Clifford Jun 03 '10 at 16:51
  • @Clifford you are right, my example above is very simplistic; but that is the point: the use of goto I propose is for complex logic, which is not easily demonstrated by a simple example. Now, in some complex problems, I've found that a simple goto is more direct and clear as to what the intention is better than other solutions. – Gianni Jun 03 '10 at 17:07
  • @Clifford are you proposing multiple return statements within a given function? – simon Jun 04 '10 at 00:18
  • @simon: No, I merely adapted Gianni's structure into the most obvious solution without goto. Multiple returns is a separate argument, and I accept only marginally better. The comment box does not lend itself to describing a better solution, but since the example is contrived, I chose to ignore that point. – Clifford Jun 04 '10 at 08:52
  • @Gianni: Perhaps you have over complicated your example in order to contrive an example, but if it is an example of the kind of "complex logic" that leads to acceptable use of goto, I would suggest that the first resort should be to reduce the complexity. I would call this 'convoluted' not 'complex' – Clifford Jun 04 '10 at 08:55
  • @Clifford: I actually fond a piece of my own code where I use goto. Then tried to reduce it to a meaningful example. Complex logic is a fact of life, our job is to handle this complexity, and I find that sometimes goto is a good tool for the job. Just because goto can be used to create the worst possible code, does not mean that evey use will be bad. – Gianni Jun 04 '10 at 13:59
  • Often this idiom is useful for freeing dynamically allocated resources at the end of a function with many possible early exit points (error conditions on system calls, etc.) – PBJ Mar 06 '11 at 20:58
-2

My personal opinion is that there are NO acceptable uses of the goto statement in a modern programming language.

"GOTO Statement Considered Harmful", by the late Edsger W. Dijkstra, does a good job of covering the issue. That paper should be required reading for every software developer on the planet.

It is worth noting that the Gypsy language, from Don Good's group at UT Austin in the late 1970s, did not have a goto.

It is worth noting that Ichbiah et al only included a goto in Ada because the DoD required it, explicitly, in so many words in the requirements specification. I remember reading that Ichbiah and his team deliberately made the goto target label syntax as ugly as they could, to make the labels stick out like sore thumbs, and discourage use of the goto.

John R. Strohm
  • 7,547
  • 2
  • 28
  • 33
  • 1
    My personal opinion is that treating good practices like ironclad rules demonstrates either a lack of flexibility or a lack of faith in one's ability to make sensible decisions. Sometimes necessary for company policy, but not for personal policy. The best language feature to use is the one that depicts the intent and the logic in the simplest and most obvious way. This is *almost never* `GOTO`. Don't confuse "almost never" with "never". – snarf Dec 12 '20 at 17:32
  • @snarf, there are two parts to the problem. The first is the impact on the programmer and the programs he writes. Dijkstra, and others, addressed this at length. The second is the impact on the compiler, which does not get as much attention. BRIEFLY, including a goto statement in a language forces the compiler to deal with the damage it does. Goto statements make certain optimizations far more difficult: the compiler must assume that register contents are significantly less predictable. – John R. Strohm Dec 13 '20 at 00:02
  • 1
    re: "impact on the programmer", a programmer is well advised to make exceedingly rare and judicious use of `GOTO`. I've said as much—use it when it makes code simplest and most maintainable, i.e. "almost never". Re: "damage to the compiler", something something premature optimization. `GOTO` is **not** an optimization, and as in other cases, if you ever try to use it as such, you most certainly better be using a profiler. – snarf Dec 13 '20 at 20:50
  • Let me put it this way. In the almost fifty years I've been doing this, working almost exclusively in mission- and safety-critical embedded systems, I have NEVER seen a case where a GOTO made code "simplest and most maintainable". As for "something something premature optimization", you are mistaken. Urs Ammann hit this specific point in one of his papers about the early PASCAL compilers he wrote at ETH-Zurich. – John R. Strohm Dec 14 '20 at 01:08
  • 1
    If you're dealing with "safety-critical" software (ten seconds or fifty years, doesn't matter), hopefully you're operating with more stringent coding standards. At any rate, if you've already decided it's always wrong, it's never going to seem right. So we're just going in circles on that count. How am I mistaken about premature optimization? I think you misread what I said? Unless you're advocating for premature optimization. Or have some aversion to profiling. I encourage everyone to free their mind. Use a `GOTO`. Does it make your code worse? Take it back out! Just don't be afraid to try. – snarf Dec 14 '20 at 04:16