use of goto in C
in [ASM]
|
Prev: on goto
Next: HLA v2.9 is now available on Webster
From: Rod Pemberton on 26 Apr 2010 05:06 "Alexei A. Frounze" <alexfrunews(a)gmail.com> wrote in message news:59eed8de-fa97-42f9-8550-8154ac69a167(a)h16g2000prf.googlegroups.com... > > If you restrict the use of goto in C/C++ to several simple patterns > and write your code carefully, goto's aren't really a problem. > But, are goto's of any advantage in C over other solutions? With optimization and good code structuring, is there any place that a goto is the best choice? "break" and "continue" function like goto's - without needing goto labels... If "break" is used with "while(0)" code block, it is functionally the same as using a forward goto. "continue" can be used for a backward goto... IMO, this means simple usage of goto is no better than using structured C control flow. That leaves more complicated situations where goto might have some advantage. The most common arguments for their use is 1) to break out of multiple, say three or more, nested loops or 2) error recovery. Status flags, fall-through, using a switch, restructuring the code blocks, reducing the number of loops, can all be used to fix such problems. Is there some situation that really advantages a goto?... C has a robust flow control syntax. About the only thing that can't be done readily is to detect if a while() loop was executed. The need for this is exceptionally rare, IMO. You could use status flags, at the expense of another variable... But, it's handled easily by adding an if() around the while() with the same set of conditions: A) while(conditions) { /* loop stuff */ } /* did loop execute or not? */ B) if(identical_conditions_as_while) { while(conditions) { /* loop stuff */ } /* if here, loop executed because */ /* conditions of if() while() are the same*/ } > ... several simple patterns ... Like? Rod Pemberton
From: Rui Maciel on 26 Apr 2010 06:43 Rod Pemberton wrote: > But, are goto's of any advantage in C over other solutions? With > optimization and good code structuring, is there any place that a goto is > the best choice? Yes, finite state machines. You can do those by putting a switch() on a loop but in the end that is nothing more than a crude hack used to desperately (and irrationally) avoid using goto. Rui Maciel
From: Robert Redelmeier on 26 Apr 2010 09:02 In alt.lang.asm Rod Pemberton <do_not_have(a)havenone.cmm> wrote in part: > But, are goto's of any advantage in C over other solutions? > With optimization and good code structuring, is there any > place that a goto is the best choice? > > "break" and "continue" function like goto's - without needing > goto labels... If "break" is used with "while(0)" code > block, it is functionally the same as using a forward goto. > "continue" can be used for a backward goto... > > IMO, this means simple usage of goto is no better than using > structured C control flow. That leaves more complicated > situations where goto might have some advantage. Precisely! In small [teaching] examples, GOTO looks obviously messy, confusing, "jumpy" and what have you. IOW, harmful [Dijkstra] But structure _does_not_ scale! One if..then..else or case() looks great. But when you have them 9 deep they are marching off the page (formatting is a big part of the additional clarity) and [worse], a bug in the substructures has the potential to mess up the overall control flow. Misnesting. GOTO _is_ messy. But it scales -- just lookup the target in the symbol table. You do _not_ need to parse or worry about any intervening code. As a concrete example of the unsung benefits of GOTO, please consider a text editor with letter commands. In C you'd do this as a case() or switch() statement. It will be huge since each of the commands may be quite involved. A structural bug in (a) could affect (b). The compile may catch some of these, but cannot when they are "paired", even far apart. A compiler should not be used as a debugging tool. In ASM (or C if it'll do this), you'd implement via a jmp table (`jmp [ebx]`) and terminate each of the letter functions with `jmp keyloop`. Or the equivalent call [ebx]/ret. More or less how the C compiler will code it anyways. obTroll: In many ways, GOTO is reminiscent of the slightly more recent calculator debate between fans of TI algebraic notation and HP reverse polish notation. -- Robert
From: Alexei A. Frounze on 26 Apr 2010 13:17 On Apr 26, 2:06 am, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote: > "Alexei A. Frounze" <alexfrun...(a)gmail.com> wrote in messagenews:59eed8de-fa97-42f9-8550-8154ac69a167(a)h16g2000prf.googlegroups.com... > > > > > If you restrict the use of goto in C/C++ to several simple patterns > > and write your code carefully, goto's aren't really a problem. > > But, are goto's of any advantage in C over other solutions? With > optimization and good code structuring, is there any place that a goto is > the best choice? > > "break" and "continue" function like goto's - without needing goto labels.... > If "break" is used with "while(0)" code block, it is functionally the same > as using a forward goto. "continue" can be used for a backward goto... while(0 /*shouldn't it actually be 1 because with 0 it won't execute even once*/) looks like a legitimate loop at first until you have found that all the breaks out of it. What's worse it introduces an extra nesting level, so, if there's another loop inside, breaking out the inner one won't be as simple as still doing goto -- you'll still have to implement some variables or whatnot in order to do what a single goto would. > IMO, this means simple usage of goto is no better than using structured C > control flow. That leaves more complicated situations where goto might have > some advantage. > > The most common arguments for their use is 1) to break out of multiple, say > three or more, nested loops or 2) error recovery. Status flags, > fall-through, using a switch, restructuring the code blocks, reducing the > number of loops, can all be used to fix such problems. Is there some > situation that really advantages a goto?... I'm using goto almost exclusively for the above two scenarios. For everything else its ifs and switches (and ?: at times). > C has a robust flow control syntax. About the only thing that can't be done > readily is to detect if a while() loop was executed. The need for this is > exceptionally rare, IMO. You could use status flags, at the expense of > another variable... But, it's handled easily by adding an if() around the > while() with the same set of conditions: Yeah. But if you're linearly searching for something, then you begin with an invalid index or NULL pointer and after the loop you just examine it and see whether it has become valid or not and you don't always need an extra variable. Alex
From: Rod Pemberton on 27 Apr 2010 02:38
"Alexei A. Frounze" <alexfrunews(a)gmail.com> wrote in message news:3175dd42-6ff2-452b-af2e-93de277ec661(a)t14g2000prm.googlegroups.com... On Apr 26, 2:06 am, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote: > > while(0 /*shouldn't it actually be 1 because with 0 it > won't execute even once*/) > Eee... Good catch! Sorry, that doesn't work. But, no, definately not "while(1)"... That'd would be a loop. How about "do {} while(0)"... With a "break" or "continue", we should have a forward or backward goto. If the "break" or "continue" is not executed, the entire section only executes once, as if the "do {} while(0)" was not there. Hopefully, that's correct this time? :-) Rod Pemberton |