goto statement
-
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.
OriginalGriff wrote:
it violates all the principles of good code design
Actually "good" code design is an evolving thing. When I started coding, spaghetti code was normal and "good" I much prefer today's standard of "good" and look forward to new definitions of good. Just read an article about how we should eliminate IF statements. Interesting, but you can see how the "IF" was encapsulated in the routine executed. But that is part of the new "good", encapsulate and re-use existing logic.
-
"Clever" use of GOTO can create macramé like code that is impossible to debug.
I may not last forever but the mess I leave behind certainly will.
Herbie Mountjoy wrote:
"Clever" use of GOTO...
Not only difficult to debug, it makes it difficult to alter. I ran into code that had an if goto, code, if not goto, unlabeled code. I didn't dare change it by removing the code that would never get executed. I didn't know why the code was there or what it was supposed to do or if I missed something "clever" done.
-
No, I was not referring to runtime recursion you'll be pleased to know. That would be horrendously inefficient - and in my experience when you're writing code like this efficiency is often an issue. I am talking about code generation, but letting the compiler do the work for you using template metaprogramming. Modern C++ supports variadic templates, so a Tuple class can be declared something like:
template class Tuple : public Tuple
{
// ...
};That is a tuple of any number of arguments, each of any type. Your CompareTo function can then be written using recursion that occurs entirely at compile-time. This does require a detailed knowledge of template meta-programming though, and is certainly beyond me explaining in a short response here. Luckily, the standard library already includes such a class named
std::tuple. Here's a short example of its use:#include #include int main()
{
auto t1 = std::make_tuple(1, 2, 3, 4, 5);
auto t2 = std::make_tuple(1, 2, 3, 4, 6);if (t1 < t2) std::cout << "Less" << std::endl; else if (t1 > t2) std::cout << "Greater" << std::endl; else std::cout << "Equal" << std::endl; return 0;}
Given two tuples, this will actually generate at compile-time code more or less equivalent to the example you gave above. Indeed, given the two tuples defined above, a good compiler will simply realise that all the values are known at compile time, using Visual C++ 2013, I checked this. The program I just gave generates assembly that is equivalent to writing:
int main()
{
std::cout << "Less" << std::endl;
}Sadly, you need to be using a really modern compiler for this goodness - VC++ just added support in 2013 - but it least its now supported by the most recent versions of all the major compilers. PS. If you really want to see the dirty details involved in this sort of metaprogramming let me know, it just may take me a bit longer to compose - I'm still finding my feet with this stuff myself.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
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++.
-
1. If it is critical that your code is correct, don't use
goto: it has the capability to jump out of or into one or more nesting layers - even backwards - and thus makes it considerably harder to verify the correctness of the code. 2. If there is more than one programmer on the team, don't usegoto: using it makes it considerably harder for another programmer to understand the flow of code, and what it is supposed to do. 3. If you intend to build on and maintain the code over a period of more than a couple of months, don't usegoto: viewing a piece of code that you yourself wrote a couple of months ago is often not so much different from viewing another programmers' code - see item 2 above. Please note that modern programming languages have plenty of alternatives that can be used in many cases where goto could be used. In C/C++, here are some examples: - to repeat a block of code, use afor,while, ordoloop construct rather than jumping backwards - to skip over some piece of code, use anif-block rather than jumping forward - to skip over the rest of a loop body, usecontinue- to exit out of a loop, usebreakIn C++ you should also use the standard exception handling mechanism rather than usinggotoas an error exit mechanism. (There is no equivalent in C, so you might argue that in C the use ofgotofor that purpose is acceptable - but see below!) The main reason however that you shouldn't usegotois that there is no benefit. Over the past 30 years I've used, learned about, read about, and had plenty of discussions aboutgoto. 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.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.
-
After using FORTRAN for far too long (up to Fortran-77) with it's use of GOTO and, even more obfuscating, computed gotos, I started using C. However, I was self-taught and was therefore never was taught by anybody that there was a GOTO in the language! I used C for several years, then C++ and now I am firmly in the C# camp. I personally have never used GOTO in any of that code and was shocked one day to find a GOTO residing in someone else's code I had to fix. It was a revelation as big as finding out that one is allowed to use guns during a penalty kick-off. I didn't even know the syntax existed! The whole point of my argument is that I never felt the need for a GOTO at any time, ever - so I didn't miss it. I didn't make artificial constructs to get around using GOTO; I didn't deliberately re-write my code to avoid using one; it just came about naturally that I didn't ever need one. Having said that, I am sure that GOTO may be useful in some real-time code somewhere for performance reasons. My real bug-bear is with multiple RETURNs. I do actually go out of my way to avoid them and re-write them out of existence wherever I find them. I have not yet found any instance where multiple RETURNs from a method has been necessary. I miss allowing the drop through of CASE statements in a switch that has been removed in C#, forcing me to put BREAK at the end of each part and leading me to repeat code unnecessarily now and then so I am not always in favour of compiler/syntax restrictions in a language but I wish multiple RETURNs had been proscribed in the same way.
- I would love to change the world, but they won’t give me the source code.
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 select -
Nearly all the static code analysis tools I know are operating on a CFG level (i.e., nothing but conditional and unconditional gotos). So, how exactly having an explicit goto may hinder code verification? And there are many benefits in using goto. Pity you failed to notice them in the past 30 years. Chances are, you never implemented a state machine or a threaded code interpreter, and you never generated code from a high level DSL.
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)
-
You are so ignorant. Mind explaining, is the OCaml byte code interpreter really can be dismissed as an example of a "bad code"? Or you simply failed to think of this particular way of using goto?
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...
-
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)
