|
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)
|
|
|
|
|
Are you deliberately avoiding commenting on OCaml bytecode interpreter example? Show me the "better alternative", or admit that your so called "experience" is deeply flawed and very limited.
|
|
|
|
|
You replied to me, not Stefan.
Or it might be that you're arguing about switch statements when this topic is about the goto. Since you haven't written that the OCaml bytecode interpreter uses gotos, it's not clear where you're going.
Plus, is there only one difference between the two implementations.
How does this compare to using virtual functions to represent state. Perhaps that would be faster still.
|
|
|
|
|
Remember
goto is a four letter word and bad things will happen if you use it...
|
|
|
|
|
No. Simple as that. the only reason to use goto is to write bad code 
|
|
|
|
|
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...
|
|
|
|
|
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[^]
modified 12-Nov-13 6:54am.
|
|
|
|
|
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)
|
|
|
|
|
As expected, a moron just managed to prove his complete lack of ability to think. Applause!
You're incompetent. Admit it. People like you should not be allowed to code.
|
|
|
|
|
Of course there are arguments against using the goto.
Have you actually read Dijkstra's paper? I did, and it was not a joke.
I also read Hopkin's paper, "A Case For The Goto".
That was a serious paper too.
|
|
|
|
|
Most of the first and second-generation languages were conceptually founded on some problem-oriented model. In focusing on a particular problem space, they tended to neglect other considerations. One result was that many languages were merely "assembler with better syntax" -- and the GOTO or branch instruction is impossible to do without in that scheme.
Third-generation languages such as Algol and C began the move away from a hard problem orientation. They focused on other desiderata, such as structure and legibility. With the expansion in the variety of conditional and iterative control structures they offered, the GOTO became less necessary. That caused Dijkstra and others to study the relation between the GOTO and legible / comprehensible program design, and to reach the conclusion that the GOTO is harmful in the great majority of cases.
All that having been said, there are still occasions when writing a GOTO is better practice than what it would take to avoid it. Indeed, some such cases involve using a GOTO to improve legibility and maintainability; transfer of control to a procedure's error handling exit is sometimes like that. However, it's best to be biased against GOTO, and to use it reluctantly, because 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.
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
Fran Porretto wrote: 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.
Ooooh, I like that! Can I use it in my sig? 
|
|
|
|
|
(chuckle) Feel free. It was spontaneous, but the more I ponder it, the more accurate it seems!
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
Yes, I can agree that the goto statement can be confusing and I've never found a good use for it. However what is the difference between a goto and a exceptions? Exceptions are only suppose to be used for things that should never happen. Most of the time that I've seen them used for all error-handling methods. (E.G. Invalid user input) However I find throwing exceptions for this purpose, even with the performance hit, useful. It keeps the code cleaner and shows the next guy what I expect to happen. Just wondering what you thought?
P.S. I once worked in a 4k memory space divided into 2 sections. The only way to get to the second memory space was with a goto statement.
|
|
|
|
|
In 1974, my manager asked me to evaluate the new, highly touted discipline called "structured programming."
I was skeptical. At that time, I was programming in COBOL. In those days, COBOL was somewhat deficient in the amount of control structures provided. I had not yet read Bohm and Jacopini so I had no idea that the control structures of COBOL were more than adequate for the task. I suggested that I wait to perform a structured programming experiment until a new project came along.
In July, I was assigned a new project. The Chief of Naval Operations (CNO) Budget Office was in need of a text editor that could edit the descriptive portions of records in an indexed sequential file. The program would be developed and executed on a Unisys 1106 main frame computer. Unfortunately, the Budget Office also knew about the University of Maryland Text Editor (med) which, for all intents and purposes, replaced the Unisys provided editor (ed). The Budget Office wanted the interface to be "just like med" a seemingly impossible job for the short project time (three months). Fortunately, I found that med contained an API that would allow me to use the editor against the textual fields of the indexed sequential file.
So it began. For this project I could not use a GOTO statement, a standard tool of the COBOL programmer of those days. I struggled with the problem. It wasn't that the solution was difficult; the solution was difficult without using GOTOs. Finally, in September, I finished. When queried by my manager, I told him that the programming effort took longer than it would have had I not used the structured programming paradigm. We agreed that, even though some rather impressive academians had suggested that structured programming was the way to go, we would shelve further use of the method. I placed the code listing in one of the drawers of my desk and returned to programming in my normal unstructured way.
Then, in December, I received a call from the CNO production office. It appeared that a program that I had written had blown up. The production office provided the symptoms and the name of the program. I looked in my drawer and found the flawed program. When I opened the listing, I realized that this was the program that I had struggled with. As I reviewed the code, in light of the comments provided by the production office, the bug just seemed to jump from the page. It was such a simple error. But had I written the code in my normal manner, I would never have found the problem so quickly. After about fifteen minutes, during which I recoded, recompiled, and rebuilt the software, I called the production office and advised them that the software was ready for reinstallation. Neither they nor I could believe how quickly the bug was found and fixed.
Since that December day in 1974, I haven't used a GOTO statement in my work (excluding assembler, of course).
Gus Gustafson
|
|
|
|
|
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...
|
|
|
|
|
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)
|
|
|
|
|
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.
|
|
|
|
|
The argument about forgetting a break statement is not valid as that could apply to forgetting a goto statement too.
And, the Strategy pattern can implement a state machine. There aren't just two alternatives.
|
|
|
|
|
|
During 30 years as programmer - I did not find any case for using GOTO instead break/return/exit_conditions.
|
|
|
|
|
If it was so evil, why is it still there? Mosquitos that spread malaria are around for a reason. Right now, because it causes so many deaths (program crashes?) and suffering (coders finding code difficult to track), we think they're bad. They are there for a reason (keeping human population in check?): all you have to do is figure it out and learn how to respect them (don't create insecticide resistant varieties) and use them properly.
If you have nested loops, how would you jump straight out? Have nested routines with exits? Throw pretending that it is not a goto? Set lots of flags and check them every time? longjmps (goto in function form) are just a variant of goto. Why don't you just use a goto instead of wrecking your brain how not to use one.
If you don't wish to use gotos (squeezing the toothpaste tube in the middle) you don't have to (roll it from the end). Like a toothpaste tube that may not be squeezed the way you like it, you can choose to live with it or let it annoy you. If it annoys you that much, you could use gotoless languages (tooth powder?) like Bliss or Python.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
