>>6
CAN YOU HEAR ME UP THERE FROM THAT NESTED PYRAMID OF ITS OF YOURS? I THINK YOU'RE WRONG. I THINK WHEN TO VIEW CODE YOU HAVE TO SCROLL RIGHT IT'S NOT OKAY.
>>1
Please read "GOTO Considered Harmful" for the origin of this.
When you can pick a random point in a program and jump to it, you have can no longer have guarantees about what the state of the program is at any given moment. This is the reason that gotos in "modern" languages are restricted.
And in the usual case, higher level control constructs better express your intent and save you from having to make up stupid labels which just clutter up your program.
>>1
Listen to >>11 but keep in mind that goto can save you a lot of code, readability, and sometimes speed in tight loops. grep -rI goto /usr/src/linux
I usually only use goto (or its equivalents in other languages) for these purposes:
1) When breaking out of nested loops in C-like languages which don't provide multi-level break/exit statements/operators (some fancier languages do provide much better solutions for this, Common Lisp comes to mind almost immediately). Also used for cleanup/error handling in C as well when it makes sense to do so. Usually you should only use goto (or equivalents) when you can't use a more specific statement that the language provides to solve the problem. Of course, you can in many cases avoid goto by adding useless conditionals (which could slow down the code), but since that new code is not semantically equivalent to the one with the most straightforward goto, it's usually a fine use scenario.
2) For performance reasons in certain very tight loops. It can be a great time saver if the only alternative is to add a conditional which would have to get executed a lot more often and thus diminishing the overall performance, possibly by quite a lot. (One notable example that happened to me was some crypto bruteforce code where every memory access and compare counts. It got a 3 times speedup, leading to results being found in 1.5 minutes as opposed to 4-5min).
3) In generated code. There's absolutely no shame in using goto's here as all compilers do translate a lot of control-flow constructs to goto's (or jumps if you wish). I've used it quite a few times in CL macros. The gotos themselves don't obscure the intent of the code as they're not really visible (they're internal details that the compiler will have to handle, and the labels are gensyms anyway). Of course, TCO+lambda is more powerful than goto, and throw/catch, block/return-from, ... are also more powerful than it, but they can also be overkill (stack unwinding), however I fear discussing this further won't really help OP much as this is far from the usual C territory (albeit, you can achieve a lot of this in C, some as is, other with compiler hacking, but if you do that, all bets are off anyway).
4) Another legitimate case are state machines, a lot of times they can be described most naturally by the use of goto, and their translation is most natural. One could probably say the same for translating code written in other languages or obscure assemblies (both automatic translation or manual). For example, you could translate some of Knuth's olde recipes. Of course, most of Knuth's algorithms can be written in goto form if you translate them directly, but then you can rewrite them in a way that makes more sense and is properly structured code, however having the option to do it either way is useful.
>>19
"oh no not recursion remember the good old days when you knew exactly the size of the stack at any one point remember those days well they were good weren't they"
>>22,18
There's a lot of ways of handling state machines. For large ones, I tend to use the more high-level approach (such as chained lambda's that take advantage of TCO), however for small ones, using go(to) is pretty straightforward and does not seem in any way bad since it naturally expresses the state transition.