goto statement
-
and i thought this must be a trolling competition- i mean the goto debate is over for decades now. seriously- there are many arguments against gotos (as already posted in this thread) and i have yet to find problems better solved with goto instead of proper object orientation. ad bad code: working code != good code. that code works is the foremost and basic assumption- good code easily readable, understandable, maintainable and extensible- all things where goto brings nothing to the table- on the contrary it may (and has) severely hinders it...
Goto "debate" is not over. Dijkstra had a bit of trolling, and now hordes of incompetent dummies are taking his jokes as some kind of sacred revelation. There are *no* arguments against goto, besides complete ignorance of the opponents. I pointed to several code examples which absolutely *must* use goto. And you, goto haters, as usual, ignored the uncomfortable truth. Mind explaining, how would you rewrite OCaml bytecode interpreter without goto? Code is here, in case if goto haters are as low as I suspect and cannot even use google: https://github.com/ocaml/ocaml/blob/trunk/byterun/interp.c[^] And please, mind explaining, how exactly this Knuth's code is "unreadable": http://www.literateprogramming.com/adventure.pdf[^]
-
Tools can only get you so far, and they're not suitable for prooving code correctness. So I'm not sure why you brought that up. As for benefits, I've read and taken part in countless discussions, and not a single example brought up managed to convince me. In every single case there was a suitable alternative using standard control statements. Most of the time the person bringing up either didn't come up with the proper way, or considered the effort of writing 2-5 additional lines of code too much to bear. Based on that experience I'm convinced that there is always a better alternative. People claiming otherwise are just not sufficiently experienced to see it, or understand the need. That said, all this assumes you're looking at code where proper coding guidelines and style even makes sense to take care of: if you're just programming away a piece of throw-away-code, then yes, use whatever suits you best and solves the problem. In actual production code that is going to live through years of maintenance and adding features, the presumed benefits of goto never outweigh the long term maintenance problems.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Funny. It was YOU who brought the correctness and verification issue up. I would never imagine mixing it into a goto discussion. Proving code correctness always involves operating on CFG, no matter if it is a manual or automated proof. Your precious structured coding constructs are eliminated long before you can do any useful reasoning about the code. For a "single example", are you blind?!? Never seen Linux kernel? Then how can you refer to your nearly non-existent "experience"? Or, take this code and make it better: [^] I am 100% sure you cannot keep the same performance without goto. Show me that pathetic "better alternative".
-
Stephan_Lang wrote: "The main reason however that you shouldn't use goto is that there is no benefit. Over the past 30 years I've used, learned about, read about, and had plenty of discussions about goto. In all that time I've never heard or read one compelling argument in favor of using it. Yes, you can use it to reduce or avoid nesting, or otherwise reduce the amount of code. But that by itself is not a valid argument in my book." Over the past 39 years, I've never used a goto in C or C++. I did use the goto in Basic. My first computer only had GWBasic and assembly language. Some situations where there is a benefit to a using goto are mentioned in Hopkin's 1979 paper, "A Case For The Goto", which I believe was written in response to Dijkstra's paper, "A Case Against The Goto". Even with modern compiler optimizations, the examples in both papers still apply today. I would, and have, gone to extreme lengths to avoid using a goto, for the reasons you mentioned. Even when I've had to jump out of the center of multiple nested loops, I used an exit-flag and an if-statement with a break after each loop. Still, there is no question that this is a bit slower than using a goto to jump out of the center. I have coded many real-time Digital Signal Processing algorithms with streaming data. Often these algorithms must be fast enough to keep up with the input data stream. In some cases, I have had to write special assembly code routines for some calculations, otherwise the algorithm couldn't keep up with the input data. Unfortunately, unlike the C language, assembly language isn't portable. Using a goto is likely to only result in a very small speed increase. I doubt that using a goto is typically justified, if it is ever justified. Still, there can be a benefit to using one, and I acknowledge that there might be some fringe case where, after other necessary algorithm and implementation optimizations have been done, using a goto is warranted. Thus I reject any dogmatic statement to the contrary. I say, as a general rule, use all possible techniques to avoid using a goto. I've always been able to avoid the goto. You can probably avoid the goto too. Check out one of the links in my first message in this thread where issue of dogma and the 'goto' is addressed. I also showed a loop construct as a way to avoid using a goto in some situations in that message.
-
Take a look at this decades old code - I bet you can easily read it: http://www.literateprogramming.com/adventure.pdf
My point wasn't about code that died decades ago, but code that continued to live and be modified over decades! Readability is just one aspect, maintainability is more important. Besides, the author himself stated in the comments that his reason for using goto was implementing multistate transitions. Come on! I've used tools to generate those automatically from UML 10 years ago! And I could even choose if I wanted to generate the statemachine using swicth or inheritance! In other words, there are valid alternatives and even tools that help you generate the code.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
Stephan_Lang wrote: "The main reason however that you shouldn't use goto is that there is no benefit. Over the past 30 years I've used, learned about, read about, and had plenty of discussions about goto. In all that time I've never heard or read one compelling argument in favor of using it. Yes, you can use it to reduce or avoid nesting, or otherwise reduce the amount of code. But that by itself is not a valid argument in my book." Over the past 39 years, I've never used a goto in C or C++. I did use the goto in Basic. My first computer only had GWBasic and assembly language. Some situations where there is a benefit to a using goto are mentioned in Hopkin's 1979 paper, "A Case For The Goto", which I believe was written in response to Dijkstra's paper, "A Case Against The Goto". Even with modern compiler optimizations, the examples in both papers still apply today. I would, and have, gone to extreme lengths to avoid using a goto, for the reasons you mentioned. Even when I've had to jump out of the center of multiple nested loops, I used an exit-flag and an if-statement with a break after each loop. Still, there is no question that this is a bit slower than using a goto to jump out of the center. I have coded many real-time Digital Signal Processing algorithms with streaming data. Often these algorithms must be fast enough to keep up with the input data stream. In some cases, I have had to write special assembly code routines for some calculations, otherwise the algorithm couldn't keep up with the input data. Unfortunately, unlike the C language, assembly language isn't portable. Using a goto is likely to only result in a very small speed increase. I doubt that using a goto is typically justified, if it is ever justified. Still, there can be a benefit to using one, and I acknowledge that there might be some fringe case where, after other necessary algorithm and implementation optimizations have been done, using a goto is warranted. Thus I reject any dogmatic statement to the contrary. I say, as a general rule, use all possible techniques to avoid using a goto. I've always been able to avoid the goto. You can probably avoid the goto too. Check out one of the links in my first message in this thread where issue of dogma and the 'goto' is addressed. I also showed a loop construct as a way to avoid using a goto in some situations in that message.
I may be bordering on dogma, but as I stated above, I've never seen any good C/C++ example where using goto was the better alternative - at best you could argue that it wasn't conceivably worse than using standard control statements. That's not to say that there aren't examples in favor of goto, in C/C++ or other languages. I just haven't seen any yet.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
My point wasn't about code that died decades ago, but code that continued to live and be modified over decades! Readability is just one aspect, maintainability is more important. Besides, the author himself stated in the comments that his reason for using goto was implementing multistate transitions. Come on! I've used tools to generate those automatically from UML 10 years ago! And I could even choose if I wanted to generate the statemachine using swicth or inheritance! In other words, there are valid alternatives and even tools that help you generate the code.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
OCaml is a live, thriving project with many new contributors. It's perfectly maintainable, and, in my books, an example of the perfect C coding style. Linux has megabytes of commits every week. Far from being "dead for decades". So, what are you talking about? What's the point of generating code which is perfectly readable anyway? State transition is, essentially, goto. Any higher level language will feature the semantically equivalent construction to represent state transitions. Yes, arrows in your UML are not any different from goto.
-
I may be bordering on dogma, but as I stated above, I've never seen any good C/C++ example where using goto was the better alternative - at best you could argue that it wasn't conceivably worse than using standard control statements. That's not to say that there aren't examples in favor of goto, in C/C++ or other languages. I just haven't seen any yet.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
OCaml is a live, thriving project with many new contributors. It's perfectly maintainable, and, in my books, an example of the perfect C coding style. Linux has megabytes of commits every week. Far from being "dead for decades". So, what are you talking about? What's the point of generating code which is perfectly readable anyway? State transition is, essentially, goto. Any higher level language will feature the semantically equivalent construction to represent state transitions. Yes, arrows in your UML are not any different from goto.
-
Goto "debate" is not over. Dijkstra had a bit of trolling, and now hordes of incompetent dummies are taking his jokes as some kind of sacred revelation. There are *no* arguments against goto, besides complete ignorance of the opponents. I pointed to several code examples which absolutely *must* use goto. And you, goto haters, as usual, ignored the uncomfortable truth. Mind explaining, how would you rewrite OCaml bytecode interpreter without goto? Code is here, in case if goto haters are as low as I suspect and cannot even use google: https://github.com/ocaml/ocaml/blob/trunk/byterun/interp.c[^] And please, mind explaining, how exactly this Knuth's code is "unreadable": http://www.literateprogramming.com/adventure.pdf[^]
vl2 wrote:
hordes of incompetent dummies
says who?
vl2 wrote:
There are *no* arguments against goto
At this point the discussion with you is over. I did make the mistake of spending time to look into some of the things you linked to, because I was genuinly interested in good examples in favor of goto. But now I realize you are but a troll. BTW, most of Knuth's code is unreadable by todays standards. Welcome to the third millenium.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
Mind naming a language feature which is semantically closer to the notion of "state transition" than a simple goto?
switch
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
switch
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
No way. Switch is semantically more complex, and if you want to implement state machine over it, you need to introduce additional entities - namely, current state variable. And, in case of C, there is a horrible way to fail by forgetting a break statement - which also has nothing to do with the essence of a mere state transition.
-
vl2 wrote:
hordes of incompetent dummies
says who?
vl2 wrote:
There are *no* arguments against goto
At this point the discussion with you is over. I did make the mistake of spending time to look into some of the things you linked to, because I was genuinly interested in good examples in favor of goto. But now I realize you are but a troll. BTW, most of Knuth's code is unreadable by todays standards. Welcome to the third millenium.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
of ocaml is your idea of perfect coding style we have very different views how good codes looks or reads.
Ah, let me guess, your brain is mutilated by that pathetic OOP thingy? Ok. Carry on writing your buggy, slow, unreadable code. But do not lecture the real programmers on how to do things the right way. You'll never be able to implement a bytecode interpreter faster than this one.
-
I have read "Modern C++ Design" by Andrei Alexandrescu, which covers template metaprogramming in great detail. I use it, however, I don't use it when there is a simpler solution. In this case, the code is auto-generated by another program that writes the entire file. Also, the code I posted is written in C#, not C++.
I was aware this was C#, I was simply saying that this is an area where templates (as opposed to generics) pay dividends.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Ah, let me guess, your brain is mutilated by that pathetic OOP thingy? Ok. Carry on writing your buggy, slow, unreadable code. But do not lecture the real programmers on how to do things the right way. You'll never be able to implement a bytecode interpreter faster than this one.
-
Because in nearly every case I have seen of it's use in C# or C++ it has been unnecessary, and only served to both confuse the code and show that the person who used it did not understand what he was doing.
gotois not evil - but it is a "rule breaker" in that it violates all the principles of good code design and so using it should only be done with care. The problem is that it it taught on courses by lazy tutors as an easy way to get them started and then gets abused later because the students consider it "Normal" and don't learn to structure code well in the first place as a result. If you had grown up withGOTOas pretty much the only form of flow control (as I did) you would probably understand how easy it is to create impenetrable code with it, and why it should be discouraged until the coder is experienced enough to know when it is appropriate. About five years of "real" coding should be enough. But by then, he is probably experienced enough to know that there are probably better ways to achieve the same result...The only instant messaging I do involves my middle finger. English doesn't borrow from other languages. English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
It (goto) is unattractive certainly, and it's usage rightly deprecated. But for my money it's a mere misdemeanour compared to the worst sin in programming, namely global data. There are developers who would rather eat their own limbs than use a goto, yet happily employ global variables with lavish abandon, supremely oblivious to the misery they are imposing on those who inherit their code. I'm currently engaged in modifying a legacy VB6 app comprising around half a million lines of code. The many goto's therein are tiresome but just about tolerable. The multitude of global variables, all absolutely unnecessary, all toxic in the extreme, guarantee that an innocent change in one source file results in incomprehensible failures in a dozen others. I'll happily deal with all the goto's a naive developer cares to throw at me, if they would just understand and apply the simple notions of encapsulation and data hiding. Not that I'm justifying the goto mind, but there are far, far worse offences.
-
Ah, let me guess, your brain is mutilated by that pathetic OOP thingy? Ok. Carry on writing your buggy, slow, unreadable code. But do not lecture the real programmers on how to do things the right way. You'll never be able to implement a bytecode interpreter faster than this one.
vl2 wrote:
You'll never be able to implement a bytecode interpreter faster than this one.
One however might suppose that there are at least a couple of programming jobs out there where one does not need to implement a byte code interpreter though. Might even be a few lines of code from those jobs that maybe one or two other developers might need to maintain in the future as well. And none of which where optimal performance is a goal or even a requirement.
-
My point wasn't about code that died decades ago, but code that continued to live and be modified over decades! Readability is just one aspect, maintainability is more important. Besides, the author himself stated in the comments that his reason for using goto was implementing multistate transitions. Come on! I've used tools to generate those automatically from UML 10 years ago! And I could even choose if I wanted to generate the statemachine using swicth or inheritance! In other words, there are valid alternatives and even tools that help you generate the code.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Stefan_Lang wrote:
And I could even choose if I wanted to generate the statemachine using swicth or inheritance! In other words, there are valid alternatives and even tools that help you generate the code.
None of which however addresses whether those generated solutions are optimal performance implementations. In my experience performance optimization, based on actual bottleneck analysis, can often lead to code that is less than ideal in some other aspect such as design and/or maintenance.
-
Tools can only get you so far, and they're not suitable for prooving code correctness. So I'm not sure why you brought that up. As for benefits, I've read and taken part in countless discussions, and not a single example brought up managed to convince me. In every single case there was a suitable alternative using standard control statements. Most of the time the person bringing up either didn't come up with the proper way, or considered the effort of writing 2-5 additional lines of code too much to bear. Based on that experience I'm convinced that there is always a better alternative. People claiming otherwise are just not sufficiently experienced to see it, or understand the need. That said, all this assumes you're looking at code where proper coding guidelines and style even makes sense to take care of: if you're just programming away a piece of throw-away-code, then yes, use whatever suits you best and solves the problem. In actual production code that is going to live through years of maintenance and adding features, the presumed benefits of goto never outweigh the long term maintenance problems.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Stefan_Lang wrote:
Based on that experience I'm convinced that there is always a better alternative.
Could be. But I don't write code for fun but rather I get paid for it and it is often critical code that I can't spend weeks finding an optimal solution but rather the first one that is good enough goes out the door. Nor can I refactor millions of lines of code every two weeks every time I figure out a "better" way to do it. And neither can the guy that is going to maintain my code after I am gone.
Stefan_Lang wrote:
People claiming otherwise are just not sufficiently experienced to see it, or understand the need.
Of course there are always people willing to rationalize that their way is "best" despite the fact that they can't demonstrate that with objective data and often can't even construct a coherent argument as to why it is "best". And technology rationalizations are often based on nothing but technology while ignoring the realities of delivering software in a business environment.
Stefan_Lang wrote:
In actual production code that is going to live through years of maintenance and adding features, the presumed benefits of goto never outweigh the long term maintenance problems.
That would of course be an excellent argument if in fact none of the following was true. - Maintenance was the sole and only driving business requirement. - The business had a firm enough grasp on process control to be able to quantify maintenance costs. - The process control was structured enough that it could enforce quality on the entire rest of the enterprise and to such an extent that the trivial cost of infrequent code misuse rose above the most miniscule noise level of maintenance cost. Versus for example, no requirements, poor requirements, unused requirements, invalid requirements, zero architecture, chaotic process management, etc, etc, etc.
-
My point wasn't about code that died decades ago, but code that continued to live and be modified over decades! Readability is just one aspect, maintainability is more important. Besides, the author himself stated in the comments that his reason for using goto was implementing multistate transitions. Come on! I've used tools to generate those automatically from UML 10 years ago! And I could even choose if I wanted to generate the statemachine using swicth or inheritance! In other words, there are valid alternatives and even tools that help you generate the code.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
We essentially agree that gotos are undesirable the vast majority of the time. I'm just not positive that gotos are bad all of the time. One can develop tunnel realities, even with decades of experience. Take the saying at the end of your post: "GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)" While I expect that is often the case, I would think it untrue in some situations. If a well-managed team were to find a reason to use a goto, and the team had guidelines that were documented in the code around the goto to not do this elsewhere, then I don't think that goto's would necessarily proliferate. But again, I've always used break or continue and avoided them too, and I agree with your philosophies, just not the absolutist part of your philosophy. I don't know absolutely every situation for ever program in every context, and there actually is a documented benefit to gotos in some circumstances. Even though there can be dire consequences from using a single goto, nonetheless the tradeoff might be that without using a goto, something isn't fast enough to do that job. In that case, the developer might decide that practicality takes precedence over good software engineering. I can't prove that situation doesn't exist. So I can't be absolute about the rule. I don't get that someone posted that goto's were needed for a state machine. A switch statement works, and there are other solutions too. The book "Design Patterns" provides the Strategy pattern, which (and I expect you know this already Stefan) where different "state" classes derive from a common base class, and switching states is done by switching the type of object. Virtual methods are called on the current state object. And, except in rare instances, I suspect a goto isn't much faster than well-written code, and probably even slower in some cases. Today, often instruction cache fetch limitations, data cache fetch limitations, or instruction ordering (the last less of an issue with modern Intel compilers than it used to be) affect performance more than the number of instructions in the code path. (I know you know this too). So, in general, the only way today to find out if code is faster is to profile the code. (Note, I wrote "in general" there - of course there are exceptions). I would need pretty strong proof in a particular situation to even consider that using a got
