Comment by kevindamm | Hacker News Reader

Comment by kevindamm | Hacker News Reader

I disagree about the examples of when a go-to is useful:

> - Using a single goto and single label to exit several levels of scope.

Better handled by putting the nested scope in a function and using `return`.

> - Using a goto in the middle of complex construction to short cut to the top of a loop.

Use `continue`.

> - Starting a highly optimized do { ... } while loop that is best initiated by jumping into the center first. (Because your compiler is not cooperating.)

This one's tricky, first be sure that the optimization is actually needed. Then, with a quick glance at DRY for apology put a copy of the second half of the loop before the `do`.

> - Extensions of duff's device.

Oh come on. The original Duff's device is not intuitive when first approaching it, and there is pretty much one use for it. I wouldn't even suggest to juniors that they be aware of this trick at all, tbh. It's a curiosity but I balk at it being a justification for adding gotos to make your own custom extension of it. See above, check that you really need such a severe optimization. You likely don't.

>> - Using a single goto and single label to exit several levels of scope.

> Better handled by putting the nested scope in a function and using `return`.

I dunno, that seems pretty silly to me. It's a perfectly valid use case of goto to jump out of deeply nested loops, and refactoring it to break out the inner loop in a function seems like pointless busy-work that ultimately makes the code harder to read, just so you can avoid a goto.

@OskarS I agree with you... In fact, I have been avoiding gotos as a matter of principle for years and now reading the different discussions, I think I was misled. This case is very, very common. You have 3 intertwined loops and you want to get out. The traditional solution is to add some intermediate variables to propagate the end of the loops, with a cascade "if (toto) break;" which are far from being exquisitely elegant... Using a function for that is really adding some more complexity and some more stuff on the stack for nothing.

Also as a matter of technology, using "if" to get out of loops is bad with modern processors and their internal predictive algos.

My solution for a long time was to add the test within the "for" itself, but it is often confusing for users.

Exactly. The only reason not to use goto here is because of a dogmatic opposition to ever using goto. In fact, this is a rare case where goto makes the flow of the program more clear rather than less clear, and alternate solutions are just worse.

> put a copy of the second half of the loop before the `do`

But why is that better than just using a goto? Goto’s are usually discouraged because they make code hard to follow, but if avoiding the goto makes the code even more convoluted, whats the point?

Given that exposure to `goto` is going to be minimal born most developers born after 1980's, the use of `goto` is likely to appear more convoluted.

At any rate, the greatest danger in this case lies in the code duplication. If performance is not an issue, stick it in a function. If performance may be an issue, start off by sticking it in a function and see if compiler optimizations take care of the issue. If performance is an issue, by all means force it to do what you want by using `goto`.

While there is nothing intrinsically evil about `goto`, most of the developments in programming languages were meant to overcome challenges of the past. We shouldn't dump those developments based upon exceptions to the rule. Rather, we should recognize exceptions to to rule as being extraordinary circumstances in which those developments were not useful.

> start off by sticking it in a function and see if compiler optimizations take care of the issue.

You could also just use a goto and avoid the accidental complexity.

I still dont understand why a complicated workaround is better than a simple goto.

Reply on news.ycombinator.com