|
Clearly false since a whole bunch of language constructs compile into assembler/IL jump instructions.
|
|
|
|
|
I guess its just that abusing it can make source code hard to follow.
|
|
|
|
|
When I was a kid, I had a book with a BASIC program that generated mazes. I loved the game, but it was a mess of code. There were GOTOs that led straight to other GOTOs! (Check out line 780.) As an exercise when I got older, I went through and made it structured -- took days! That is why all the GOTO hate.
Anyway, using a GOTO on occasion isn't such a big deal. The problem is when it is the backbone of a complex program. And I agree with the person who said very few programmers come across a situation in which GOTO would be the preferred method.
|
|
|
|
|
Hmm, looks remarkably like a very basic finite state machine to me 8)
|
|
|
|
|
I agree on the state machine.
Each state has one subroutine for it.
Each subroutine could transition to one or more states.
Simple, concise.
How (and why) would a goto improve this?
Other thoughts
In assembly, ever high level loop is implemented with gotos/branches.
Java does not have or need a goto because they allow labeled break and continue statements. I don't think C# copied that feature (unfortunately).
|
|
|
|
|
Subroutines cause stack push pulls, the goto doesn't which makes it much more efficient. If you want your code to run in an ever shrinking hardware platform world things like that put you in front of the competition.
|
|
|
|
|
I think his point was that in the end, everything ends translated to gotos by the compiler.
|
|
|
|
|
Deep recursion could potentially stand to be replaced with a goto.
The problem as others have mentioned is that it has been heavily abused. And since it usually would only be needed under a limited set of circumstances it's better to just make it off-limits unless someone can make a compelling case for its use.
|
|
|
|
|
The key to any job is having the right tool.
If we start removing tools because people abuse them we would have to take computers away from people entirely. Just saying 
|
|
|
|
|
Yes, if you're working in a language which doesn't support tail recursion. This goto (and the argument reassignments) should be clearly commented as being a hack around tail recursion not working, though.
|
|
|
|
|
Try working on a limited stack-depth platform, such as the PIC16F1516 - your tune will quickly change when you hit the stack depth with your precious function calls. Without goto on that platform you'd be royally f***ed for anything more than the simple.
Tail recursion on a PIC: GOTO!
The worst thing about the darkness is the light at the end - DX-MON
|
|
|
|
|
I've been sitting here cogitating on this. Every switch statement that I write is just a calculated goto. The compiler takes care of all the gubbins behind the scene.
brian
a sig? i don't need no stinking sig!
|
|
|
|
|
englebart wrote: Java does not have or need a goto because they allow labeled break and continue
statements. I don't think C# copied that feature (unfortunately).
Incorrect. Not only are break and continue supported, they have been ported with slight syntax changes to VB.Net (e.g. Exit For/Loop, Continue For/Loop). I've used these features in both these environments.
|
|
|
|
|
Same for me, this is a state machine!!
|
|
|
|
|
Yep, seems like goto used to implement a simple "Case" statement to me too.
In fact, "If", "Case", "For", "While" are just patterns captured from observing the repeated use of "Goto"; I would imagine. Thereby simplifying the language so you as the read don't have to search through the connecting statements to realize the "Goto" is just implementing a "While" or "If" pattern.
Of course not all conceivable "Goto" pattern has been captured. Consequently, there are no doubt algorithms in which the "Goto" is either necessary or a simplier description than combinations of the aforementioned patterns, as rare as these may be.
|
|
|
|
|
George Dennie wrote: Of course not all conceivable "Goto" pattern has been captured. Consequently,
there are no doubt algorithms in which the "Goto" is either necessary or a
simplier description than combinations of the aforementioned patterns, as rare
as these may be.
Theoretically, ANY goto can be replaced with a finite state machine. Practically speaking, after ten years of trying I still never eliminated two goto's in a C module that did some rather hairy financial estimation at a former employer of mine, and I did eliminate the other several dozen or so that originally decorated the same module. It wasn't that it couldn't be eliminated, it was that the refactoring necessary to eliminate it was always too painful for the time we wanted to spend.
The fact is, though, that it's much easier to teach someone how a piece of structured code works than it is to teach how a piece of spaghetti code works. That same module was one evil monster to troubleshoot when it had its maximum lifetime gotos because it was not structured; I got permission to eliminate the gotos because the original guys who wrote it were gone, and even the owner/entrepeneur who'd come up with the algorithm couldn't explain exactly how the code was doing it, so any attempt to update or enhance it required hours to days of analysis first; after I got done, that time spent went down by at least 90%.
When you're not living with a piece of code but simply visit it every now and then, it does not pay to use any technique that you may not be able to understand easily a year or two later, especially if it's not your code but your employer's.
|
|
|
|
|
Yes, there are relatively rare examples of good reasons to use them.
99% of programmers don't do that kind of work.
You might also argue that tailgating at high speeds is OK, because NASCAR drivers do it.
|
|
|
|
|
CDP1802 wrote: Thinking and making most of the resources at your disposal is more important than blindly following rules.
Well said. My thoughts exactly. It's a matter of the right tool for the job. This is true in any field of endeavor. You use a spoon when you need one and a front-end loader when you need one of those. You don't just say "never use a spoon" once you've discovered that you have a front-end loader at your disposal. You use whichever one suits the job at hand.
GOTO makes sense in a lot of contexts, in others it doesn't. Whatever construct allows you to express the idea in code most elegantly is what you use.
I have to laugh at the religious fervor that develops over this particular subject.
-Max
|
|
|
|
|
CodeBubba wrote: GOTO makes sense in a lot of contexts, in others it doesn't. Whatever construct
allows you to express the idea in code most elegantly is what you
use.
I have to laugh at the religious fervor that develops over
this particular subject.
It's not religious fervor; it's the voice of victims of the GoTo Holocaust saying "Never again!" I speak for myself and many, many others who had to maintain code written in structured languages by programmers who didn't care to structure their code. At the time I entered programming as a profession, Dykstra's "GoTo Considered Harmful" had been published for over a decade yet many programmers still disdained use of structures even after moving to languages like C which supported a rich set of control and loop structures. This was called "job security" - after all, if only the original programmer could explain his code, obviously he needed to be kept happy, and the less readable the code was the better it served the programmer's purpose.
The biggest problem with GoTo is that is does NOT "express an idea"; it just tells you where to go next. Thus, while the code implements the algorithm, it does not express it to the reader.
That hasn't kept me from occasionally letting a goto remain somewhere where it would have been too time-consuming to factor it out. Also, goto is vital in one particular context: when otherwise code would be too large for the available memory space. Before virtual memory (i.e. the days of MSDOS) I helped maintain multi-megabyte programs loaded 256k at a time into the PC's memory, and gotos could sometimes eliminate code repetition in complex algorithms that resisted refactoring (e.g. they worked, but no one really knew how). So, I do know that gotos are sometimes necessary.
However, it is my considered opinion based on years of experience maintaining code with gotos along with years of experience first using structured programming then other forms (functional, declarative, later OOP) that if goto isn't absolutely required to solve the problem, then it is a maintenance menace because it does not express anything, requiring a programmer to parse the branches in order to understand the algorithm being expressed. This may not seem like anything to someone who routinely uses gotos, especially if you work within a group that shares the same habits and code styles, but do you remember how long it took to become an expert at what someone else's code would produce? (If your answer is "not long at all", I suggest you've never worked on anything that I would call complex). Maintenance of code in a business environment means you have to train your fellows in what you do, so if a truck turns you into a greasepot on the highway your business fails to fail because the next guy can take up approximately where you left off. I've got MSCS-level algorithms that give my partner in crime headaches, and they are all nicely structured code encapsulated in sensible objects, AND he's got a graduate degree in a real engineering discipline (thus, he's not a slouch) - I could have used a goto here and there to shorten code length, but how long would it take to explain what that's doing when he's struggling with the rest of the logic?
To anyone who has shared my experience, saying that "GOTO makes sense in a lot of contexts" suggests you "know" things that just aren't true. Show us where you thinks it makes sense, please. Who knows, after all this time I might just learn something new.
|
|
|
|
|
You may not have meant it but your tone is sanctimonious. If that's the way you intend it, it's not appreciated.
No doubt, I have (over 35 years) cleaned up a lot of messes (spaghetti code) where GOTO was misused. When I say "a lot of contexts" I mean I have run into a lot of situations in existing code where its use still makes sense and where "factoring it out" isn't profitable.
I practically never use it any more in my OO style code however, as it was pointed out earlier I believe, there are still situations (assembly code, etc) where it's use is appropriate.
I repeat: use the right tool for the job. If a developer is incompetent then GOTO will not be his only abuse.
-Max 
|
|
|
|
|
CodeBubba wrote: OTO makes sense in a lot of contexts, in others it doesn't.
I doubt that in the general sense and specifically for this site/forum.
It could be that there is a problem domain like camera firmware where the context basically requires goto.
However in the context of standard enterprise business development that is done in languages like Java, C# and/or C++ it almost never is needed.
|
|
|
|
|
When I was a professional Systemprogrammer (Assembler)we were fighting against branches whereever. This because the instruction prefetch which fails when you go out of the straigt forward. Also todays machines do that prefetching and will fail to guess the thread! So avoid going left or right - go straight on.
Jordi
|
|
|
|
|
You have to be pretty ancient to appreciate the goto controversy. I was writing FORTRAN in the mid-sixties and my oh-so-clever programs were an unreadable tangle opf goto's and labels. My initial response to Dijkstra's letter was "program without goto - impossible!". But I soon saw the need for sensible control structures.
Also, I see goto-restriction as a high-level language issue. I have never hesitated to use goto (or equivalent) instructions in assembly-language programming - often because there's nothing else. But knowing high-level control structures certainly improved my assembly style.
|
|
|
|
|
That sounds like one of my first text-based QuickBasic programs. It was a Tony Hawk menu (to store info about the game, such as cheat codes and areas that were good to get high scores).
Ah, those were the days. A shame I didn't backup the program. Pretty sure it was lost forever when the computer it was on was engulfed in flames from a garage fire my cousin accidentally set.
On second thought, probably best all evidence I ever wrote that was destroyed.
|
|
|
|
|
No, it's always a pity when something like that gets lost. Last year I found my first complete little game. It was written in CHIP-8[^]. I remember that I modified the CHIP-8 VM to relocate the video buffer and some machine language routines outside its tiny 4k address space to free as much memory as possible for the program and the graphics.
My old computer still loaded the tape and I have converted it to binary on my PC. It is now included in an emulator for those old computers. You have made me download the emulator and I have just landed on the moon (in glorious 64 x 32 pixel resolution). Want a screenshot? Here it is![^]
I'm invincible, I can't be vinced
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
