The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Mention "goto" to many programmers and they'll say, "Never use them, they lead to spaghetti code." It's a conditioned response. It seems to be a definition - "Dad, what's for dinner?" - "We're having goto." - "Again?". Ask them to explain why it is so bad, and you'll likely get a blank stare, or they just chant "spaghetti, spaghetti, …" Of course, a misused gotocan lead to spaghetti code, but a (misused) [any reserved word] can lead to [some bad thing]. Have we developed an irrational fear of goto born out of ancient coding dogma? Or is goto inherently and absolutely evil?
Update: As suggested by englebart, I'm adding why I asked this question.
It came out of a recent discussion. I was reviewing some code someone showed me (they didn't write it) that had a goto in it. He said the code was Spaghetti Code. When I asked why, he said because it had a goto. I asked why that made it spaghetti, and all he could come up with was that he was taught that. I asked about a few other "programming truths", and had much the same response. This is good, that is bad, but I don't really know why. I started thinking about how for some things, aspects of programming have become more faith than science.
That's a nice spot to use goto, I have used it twice in my life precisely for that: later I ended up removing them due to a refactor that improved every aspect of those functions (performance, readability, debuggability).
That said, I don't discard it out of hand as it is a powerful tool. As TNCaver said "You think goto is evil: try writing Assembly programs without JMP" (it has been in my signature for years... and I do also write Assembly code so it was really appropriate).
You can use goto to short-circuit time-constrained algorithms for academic or scientific purposes.
Don't use it anywhere else, especially not in a professional setting, or people will be strongly compelled to gut, rape and murder your code the first chance they get.
And can you really blame them for it?
That is true for C, but not so much for C++. goto is context dependent in C++, it will call appropriate constructors/destructors. When used in local context it will not make the function/method monolithic. So if goto is so bad, you might be using a badly outdated language?
Which is an Access Violation waiting to happen when the code changes.
How? If jumping outside block can causes access violation, then every "}" is potential access violation.
If you talk about inter-scope goto, that's is entirely different story. You can do that in C using signals. What will be the state in C++ after such goto it is indeed unknown, so that's one possible misuse of goto. But if all affected variables are on the stack (and in C++ they should be - all pointer should be wrapped into appropriate *_ptr object allocated on the stack), jumping outside of scope is completely safe. Jumping inside non-conditional scopes is also safe. Jumping inside anything else is a bad idea.
Jumping outside scope, can be realized by do-while wrapping:
// ... you can use break here
But it cannot be used inside loop/switch statement and it is utterly more ugly than goto.
That's exactly what it is. A few years ago I had to use some goto statements in a device driver written in C where the push/pop function prolog/epilog[^] was causing a performance reduction of between 30% - 40%. I could not find anything that matched the speed of the goto statement and left it in the production code.
High-performance code is almost always ugly.
Or is goto inherently and absolutely evil?
I would say that you do not need a goto statement 99.999% of the time. But I have used it at least ONE time in the past two decades where I feel it was necessary.
My education is EE, and I still see registers (68xx architecture) in my head no matter what language I'm programming in. I don't actually see the code that way, it's just kind of a background image. It's amazing how many developers don't know that the only branching a CPU has is a goto.
I've not used the goto keyword in any of my C/C++/C# code over the last 20 years or so.
I routinely use break (goto's more civilized brother, as it were) to exit for loops early. I do this in cases where expressing the iteration as a for loop is more appropriate for the general case, and the break handles the exceptions. I don't tend to use continue nearly as much in similar situations; I'm not sure why.
I dislike when code uses exceptions as an exotic form of iteration/flow control. My least favorite mechanism would have to be setjmp()/longjmp(), which is a very old C runtime library mechanism that fortunately doesn't see a lot of use today.
Yup, been there. Just after starting my first "real" job in the early PC days (company upgraded the network file server to a bleeding-edge IBM AT just after I started), I had to debug a DOS BASIC program that implemented the equivalent of function/subroutine calls by saving the return line in a variable (all global, single letter optionally followed by a single digit), setting an ON ERROR GOTO for the desired function, then forcing an exception, and using the same mechanism with the saved return line value to return. Written by a nuclear physicist, no REMarks in the code - just the physicist's hand-scrawled notes. I might be mistaken, but I seem to recall that there was a way to set the ON ERROR GOTO for different target lines depending on the exception code generated, and this was used to pick which "function" to "call" at various locations in the code.
Today, he probably would have coded the entire thing as a single Excel macro with just Row-Column cell references and of course, no labels, headings, etc.
I think it depends on the context. In C it's not so bad and I can think of a few notable examples where it is used. One instance I found rather humorous and posted in a coding 'hall of fame' page we used to have here, is in the default procedure of Windows v3.0 and the label used was "IcantBelieveIactuallyUsedAgoto." The source code of it was published in an old book by Peter Norton on windows programming.
On the other hand, I think using goto in C++ is a really bad idea. Since objects are automatically deleted when they fall out of scope, a goto could result in memory leaks if not used very carefully. As far as I am concerned this opinion is not based on fear nor is it irrational. YMMV.
Back in 1988 when I went to university to study computer science we were taught that we were never
to use goto except in one particular circumstance with COBOL.
We were strictly taught structured programming and in the first year had 2 hours of computer time each week. Most of our work was done on paper.
Fast forward to now and I am quite happy to use a return statement in code which in essence is a goto.
I think in principle it's good to learn the rules of structured programming to know when it is ok to break those rules.
“That which can be asserted without evidence, can be dismissed without evidence.”
the first year had 2 hours of computer time each week. Most of our work was done on paper.
I remember those days well!...being a CS major from around '87 to '89 when my part-time afternoon job turned into full-time, which meant almost no lab time. I quit school for 10 years and finally went back and finished. During my 10 year hiatus, I had very little contact with computers so coming back to it after a decade I was more than a little pleased to find that I could finally do homework at home...even in the wee hours of the morning!
Somewhere in a box, in a closet, are notebooks with handwritten C, Pascal, and Fortran homework assignments. I also have some greenbar printouts with notes/grade. Deliverables for an assignment were typically handwritten pseudo-code and/or flowchart and the printout which contained source code and results. That junk probably won't make the next move!
It amazes me now to think about how different it was to learn programming back then. Nowadays, an answer to a question is usually just a few clicks away, back then we relied on books, our own wits, and occasionally teachers/aides who sometimes knew little more than we did.
Thanks for the memories!
"Go forth into the source" - Neal Morse
Last Visit: 26-May-20 23:42 Last Update: 26-May-20 23:42