on goto
in [General Programming]
|
From: Richard Heathfield on 27 Apr 2010 14:45 Juha Nieminen wrote: > In comp.lang.c++ spinoza1111 <spinoza1111(a)yahoo.com> wrote: >> On Apr 25, 1:09 pm, Juha Nieminen <nos...(a)thanks.invalid> wrote: >>> In comp.lang.c++ Ali Karaali <ali...(a)gmail.com> wrote: >>> >>>> I use goto to break nested for loops and I can't see a >>>> reason to ban goto. >>> No. The correct keyword for breaking out of nested loops (in C++) is >>> 'return'. If you are using 'goto' for that purpose, you are doing it >>> wrong. >> Don't you mean "break"? > > Exactly how do you exit out of a set of nested loops with a "break"? I don't. I exit out of a set of nested loops using the conditions in the loop controllers. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Juha Nieminen on 27 Apr 2010 14:51 In comp.lang.c++ Richard Heathfield <rjh(a)see.sig.invalid> wrote: >> Exactly how do you exit out of a set of nested loops with a "break"? > > I don't. I exit out of a set of nested loops using the conditions in the > loop controllers. The idea was to make the code simpler, cleaner and easier to follow, not more complicated and contrived.
From: Richard Heathfield on 27 Apr 2010 15:01 Juha Nieminen wrote: > In comp.lang.c++ Richard Heathfield <rjh(a)see.sig.invalid> wrote: >>> Exactly how do you exit out of a set of nested loops with a "break"? >> I don't. I exit out of a set of nested loops using the conditions in the >> loop controllers. > > The idea was to make the code simpler, cleaner and easier to follow, not > more complicated and contrived. Yes. That's precisely why I use the conditions in the loop controllers. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Lie Ryan on 27 Apr 2010 15:15 On 04/26/10 17:03, Stuart Redmann wrote: > > Just to add my 2 cents: > Your statement says that break-statements (I really like the term > "goto in disguise", thank you, James) can keep the loop condition > short and sweet. I think that this is probably not the most convincing > argument for the usage of break-statements, but the readability of > code should not be underestimated. That's why I'd suggest that also > the use of continue-statements can increase the readability a lot. If > you have a look at the following piece of code (from actual production > environment): Well, every control statement is goto-in disguise. Goto is in: FORLOOP: for (...) { ... } // hiden goto FORLOOP WHILELOOP: while (...) { ... break; // hidden goto END ... continue; // hidden goto WHILELOOP ... END:} // hidden goto WHILELOOP switch(expr) { // hidden goto `expr` case GOTOLABEL_1: case GOTOLABEL_2: ... break; // hidden goto END case GOTOLABEL_3: END: } if (expr) { // hidden conditional goto ELSE ELSE: } else { } void func() { FUNCCALL: ... } // hidden goto RETURN void caller() { func(); // hidden goto FUNCCALL RETURN: ... } what else? hidden goto is so obiquitous that it's meaningless to claim that some control structure is just a hidden goto.
From: Keith Thompson on 27 Apr 2010 15:53
Lie Ryan <lie.1296(a)gmail.com> writes: > On 04/26/10 17:03, Stuart Redmann wrote: >> >> Just to add my 2 cents: >> Your statement says that break-statements (I really like the term >> "goto in disguise", thank you, James) can keep the loop condition >> short and sweet. I think that this is probably not the most convincing >> argument for the usage of break-statements, but the readability of >> code should not be underestimated. That's why I'd suggest that also >> the use of continue-statements can increase the readability a lot. If >> you have a look at the following piece of code (from actual production >> environment): > > > Well, every control statement is goto-in disguise. > > Goto is in: > > FORLOOP: for (...) { > ... > } // hiden goto FORLOOP [snip] > what else? hidden goto is so obiquitous that it's meaningless to claim > that some control structure is just a hidden goto. Exactly. The distinguishing feature of the goto statements is that it's (relatively) unconstrained. The other control flow constructs aren't gotos in disguise; they're gotos with constraints, which means that they aren't really gotos at all. Or, to put it another way, it's the "disguise" that makes them really useful. In my opinion, gotos are mostly useful as workarounds for missing language features. A goto to error handling code at the end of a function is a workaround for the lack of an exception handling mechanism. A goto to break out of a multi-level loop is a workaround for the lack of named loops. On the other hand, a goto in an explicit finite state machine implementation makes much more sense, because it directly models a concept in the problem domain (states are represented by your current location in the code, a goto represents a transition from one state to another). Though I might still prefer a switch statement in a loop, with the state represented by the current value of a state variable. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" |