Before anyone thinks about flaming me, no, I don't use goto myself. This comment got me thinking about it.

Assembler (Z80) has various jump instructions, some conditional, followed by the memory location to jump to. These differed to a call instruction in that once you jumped, you couldn't return (the address jumped from wasn't pushed onto a stack, whereas the calling address was).

With this in mind, is it wrong to use the occasional goto in code, other than for aesthetic reasons?

It's not wrong to use it were it is appropriate.

In high level languages the use of goto can almost always be replaced by some other, more elegant solution. The only place in C where I ever use goto is to break out of some large nested loop. With some other languages, you can use the syntax break label; to avoid using a goto in such a scenario as that. Even in C, it's quite possible that such a loop can be better written as a function call that returns in place of the goto.

Both Java and D use break label;. PHP uses break level;, where level is the number of loops of which you want to break out.

Goto can also be used to implement exception-like logic in languages like C. I remember having seen file access routines which had lots of potential failure points. Instead of repeating error handling code for each point, the routines used goto, which made them easier to understand.

My question is this: If you use a GOTO to break out of a function, what happens to all the local variables? Are they taken out of scope, or can they still be accessed?

Oh, and I think I should start doing this from now on:

EDIT: Fixed the labels per Simon Parzer's feedback. Thanks, Simon!

Why don't you try it?

You got it all wrong BTW...

You do labels and gotos in C like this:

ThisIsALabel:;
//some code
goto ThisIsALabel;

I don't know exactly what you posted but I think the syntax is wrong.
In my opinion you should use goto where you need it. As long as you don't plan to share your code with others.
Sometimes it even makes code simpler. I mean, I rather have a bunch of gotos and three labels than five nested loops. When I started with BASIC a long time ago I got used to GOTOs and I have no big problems with them now.
In C++ or modular C the goto statement doesn't make much sense anymore, though.

Sometimes, when writing my flow control, its difficult to implement it or think of it in terms of the standard C/C++ flow control primitives of for/while/do/switch loops and function calls. Usually in such cases I'll write what I'm thinking of in terms of loops and function calls, but do most of the flow control with if...break; and if...continue; statements and a few variables declared for the sole purpose of acting as flags for the loops.

Occaisonally though, the code will become harder to maintain, and/or debug if I write it that way, so I'll use goto statements instead. That has only happened maybe 10-20 times in the last 30 thousand lines of C/C++ code I've written, and some of those cases could have been expressed as exceptions more naturally if I hadn't been trying to avoid some issue involved with exceptions in the relevant code.

Even more rarely, sometimes I'll write something where I have such a difficult time even concieving of the flow control necessary that expressing it in terms of anything other than the natural flow control primitives I concieved of it in (often gotos for something like that) would take a great deal of diagramming and analysis and just be asking for trouble, so I write it as I concieve of it. That has only happened maybe 2 or 3 times in the last 30 thousand lines of C/C++ code I've written. Perhaps I should spend the time and effort diagramming and analyzing such cases; perhaps it would improve my ability to think in terms of the usual flow control primitives. But I'm not too sure about that. Perhaps that would merely limit my thinking to things that can easily be expressed in C/C++ instead.

Ladies and gentlemen, I give you: the computed goto in C.
The &&X syntax is a DJGPPism for : "the memory address of label X".

Compared to a switch() statement, this was way cooler IMHO, and the emulation time went from 3% to 2% (precision of this figure is low, though)

Johan, I would agree with that, unless there has to be a lot of data transfer.

Say, for example, that you have declared a bunch of data at the beginning of your function. Then, you want to test whether "a == b" and "c < d" or "e != f", etc. If you push all that data into a separate function just to do the test, it slows down the code quite a bit.

If, however, you break out of a very-nested group of loops with a GOTO, you can continue with all the data and variables you had declared/changed/etc. as if you had simply "break"-ed a bunch of times to get there...

goto jail;

When I was still learning how to program I would constantly use goto. Especially when I was first learning BASIC because the gosub command didn't make sense to me.

Learning C/C++ eventually taught me why goto was stupid for most situations.

But, I do still use it, though only in one very specific situation: To restart a procedure. My goto statements always return an executing procedure right back to where it started, or as close as is necessary for the purpose at hand, thus eliminating the need to have multiple nested do loops or recursion.

Goto is generally avoidable, but in the uncommon chance that it makes your code MORE readable than a do loop or if statement, then by all means, use it.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

I think Sun has a good reason to not even include the goto-statement in Java.