Gotoless programming
-
Exactly.
var state = 0;
while(state != 5)
{
switch (state)
{
case 0:
// ...
state = 1;
break;
// ...
}
}Interestingly enough C# turns a
switchinto a set ofgotos that use the hashcode of the test value as the jump offset (or something similar). Essentially a hardcoded dictionary - which is why it's so much quicker than repeated 'if's.He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
Exactly.
var state = 0;
while(state != 5)
{
switch (state)
{
case 0:
// ...
state = 1;
break;
// ...
}
}Interestingly enough C# turns a
switchinto a set ofgotos that use the hashcode of the test value as the jump offset (or something similar). Essentially a hardcoded dictionary - which is why it's so much quicker than repeated 'if's.He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
andrewgissing wrote:
An abstracted goto !
A switch statement in disguise :)
-
/trollattempt? See: Leppie's comment.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
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).
-
Inspired by the goto comments in the lounge today... Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company. His program had a main loop like: If var = 1 gosub 100 If var = 2 gosub 200 and so on.. and inside each subroutine before leaving, it would set var to whatever it needed to be next. An abstracted goto ! This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
The gosub call was the mechanism for calling faux functions / subroutines. Unlike the goto, the last address was pushed on the stack so the subroutine could return to the location it was called from. They were a big improvement over goto.
-
That's why I always get scared when such rules are preached religiously and then applied at all cost. I often write code for old 8 bit computers or microcontrollers and calling functions for everything will result in a slow processor working more on the stack than the actual task. Using goto or branching instructions in assembly then will make more of the two most valuable resources, CPU and memory. Thinking and making most of the resources at your disposal is more important than blindly following rules.
I'm invincible, I can't be vinced
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.
-
Inspired by the goto comments in the lounge today... Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company. His program had a main loop like: If var = 1 gosub 100 If var = 2 gosub 200 and so on.. and inside each subroutine before leaving, it would set var to whatever it needed to be next. An abstracted goto ! This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
You should try to rewrite that code with goto statements instead of gosub, and see what you get. :)
-
The reason not to use goto is not a technical one, but a code cleanliness one. A goto is an unstructured jump and makes it much harder for a human brain to comprehend the structure of the procedure. Loops with breaks and continues, conditionals, switch blocks and so on may translate to jump instructions in assembler or IL, but they're structured and therefore easier to understand. The only time I would say it might be okay is the 'double break' (i.e. breaking out of a 2D or deeper loop set). When your logic is this complex it's usually better to take the looping code out into a sub-procedure or -function and use
returninstead, because chances are that procedure is too long already. (You can always ask the compiler to inline it if you think the function stack is critical.) In modern languages, proper error condition handling (i.e. exceptions) have taken away most of the situations in which you'd want to do this. So I agree up to a point: fundamentalist 'never' dictums (dicta?) are not particularly helpful. But it is very rarely the most elegant approach to use a goto.The most common argument I hear from experienced programmers is that a goto is a convenient way to jump around in an eight level nested loop. This tells me they have mastered the function call yet. But I can see how gotos can make it easier to navigate spaghetti code.
-
Inspired by the goto comments in the lounge today... Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company. His program had a main loop like: If var = 1 gosub 100 If var = 2 gosub 200 and so on.. and inside each subroutine before leaving, it would set var to whatever it needed to be next. An abstracted goto ! This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
-
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.
-
Hmm, looks remarkably like a very basic finite state machine to me 8)
Same for me, this is a state machine!!
-
Agreed. I really don't understand the goto hate, although I've never worked in an environment where it was an issue. There are times when goto makes sense even in modern programming techniques.
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.
-
Inspired by the goto comments in the lounge today... Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company. His program had a main loop like: If var = 1 gosub 100 If var = 2 gosub 200 and so on.. and inside each subroutine before leaving, it would set var to whatever it needed to be next. An abstracted goto ! This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
Is it better to have a ridiculous number of nested levels of "if" statements? Sometimes the inability of having a goto results in a lengthy "elegant" work-around to avoid nesting purgatory.
-
That's why I always get scared when such rules are preached religiously and then applied at all cost. I often write code for old 8 bit computers or microcontrollers and calling functions for everything will result in a slow processor working more on the stack than the actual task. Using goto or branching instructions in assembly then will make more of the two most valuable resources, CPU and memory. Thinking and making most of the resources at your disposal is more important than blindly following rules.
I'm invincible, I can't be vinced
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
-
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.
-
That's why I always get scared when such rules are preached religiously and then applied at all cost. I often write code for old 8 bit computers or microcontrollers and calling functions for everything will result in a slow processor working more on the stack than the actual task. Using goto or branching instructions in assembly then will make more of the two most valuable resources, CPU and memory. Thinking and making most of the resources at your disposal is more important than blindly following rules.
I'm invincible, I can't be vinced
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
-
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.
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.
-
Hmm, looks remarkably like a very basic finite state machine to me 8)
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.
-
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 ;P