goto statement
-
Because they are ignorant idiots. Goto is absolutely essential in a number of cases. Most notable are: - Implementing state machines. The closest construction to state transition is goto, so it must be expressed as goto. - Various generated code (from higher level languages/DSLs)
gotos are definitly not essential for state machines. there are a number of patters and frameworks that are a better solution than goto hell. if this code has higher level languages as output then i dont believe gotos are required but if the code is not touched by human hands...
-
OK, from a relative novice, here's the way I see it, and pardon me, but I come from a Qbasic/VB background. As for multiple returns, if you have 10 conditions, lets say in a "Select case" statement, I see it OK to use multiple returns... if you have returns scattered, then I can see a problem. I find the following a neat way of doing this... I'm usually not much for the ":", but again I find that on something simple like this, putting the condition and the return value on the same line improves readability
Select case i
case 1 : return false
case 2 : return true
case 3 : return false
end selectThis serves as a single return as all gathered in one block
-
gotos are definitly not essential for state machines. there are a number of patters and frameworks that are a better solution than goto hell. if this code has higher level languages as output then i dont believe gotos are required but if the code is not touched by human hands...
-
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.
