on goto
in [General Programming]
|
From: James Kanze on 24 Apr 2010 18:47 On Apr 24, 1:16 pm, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > "Alexei A. Frounze" <alexfrun...(a)gmail.com> writes: [...] > > Everything may be used, misused and abused, goto included. > > There are good and bad usage patterns and goto is not an > > exception here. I can list a number of other things that may > > be just as bad as a poorly used goto (or as good as a good > > goto). See? Except that we're talking about C and C++ here, and in C and in C++, for all "good" uses of goto (and a number of bad ones), the language has specialized structures which better express the meaning. > Indeed. For example, the Duff device is worse than most gotos > I've ever seen. And it's fully structured:-). Seriously, Duff himself said that it was an argument concerning the way C implemented switch, but he wasn't sure whether it was an argument for or against. (And it should probably be pointed out that Duff used it to solve one very special problem, with one specific compiler---his code almost certainly wouldn't work correctly with any modern compiler.) -- James Kanze
From: Pascal J. Bourguignon on 24 Apr 2010 19:03 James Kanze <james.kanze(a)gmail.com> writes: > On Apr 24, 1:16 pm, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: >> "Alexei A. Frounze" <alexfrun...(a)gmail.com> writes: > > [...] >> > Everything may be used, misused and abused, goto included. >> > There are good and bad usage patterns and goto is not an >> > exception here. I can list a number of other things that may >> > be just as bad as a poorly used goto (or as good as a good >> > goto). See? > > Except that we're talking about C and C++ here, and in C and in > C++, for all "good" uses of goto (and a number of bad ones), the > language has specialized structures which better express the > meaning. > >> Indeed. For example, the Duff device is worse than most gotos >> I've ever seen. > > And it's fully structured:-). > > Seriously, Duff himself said that it was an argument concerning > the way C implemented switch, but he wasn't sure whether it was > an argument for or against. (And it should probably be pointed > out that Duff used it to solve one very special problem, with > one specific compiler---his code almost certainly wouldn't work > correctly with any modern compiler.) Well, it would depend on the C standard (perhaps the later specifications changed), but AFAIK, this is the way C is specified, and the Duff device should work on all compliant compiler. -- __Pascal Bourguignon__
From: Rod Pemberton on 24 Apr 2010 20:18 "io_x" <a(a)b.c.invalid> wrote in message news:4bd2c215$0$1136$4fafbaef(a)reader1.news.tin.it... > [Xpost to: alt.comp.programming, alt.lang.asm, > comp.lang.c, comp.lang.c++, comp.programming] > > the people that speak not good about "goto" > are uttled wrong; their code bug full etc > I learned structured programming concepts, just prior learning how to program in an unstructured language: BASIC. So, I never had a problem with GOTO's in BASIC. But, I knew someone who programmed in BASIC without using structured programming concepts. He could code very quickly. But, every now and then, he made a mistake. When he did, it was nearly impossible for him to locate the incorrect code, typically an errant GOTO. He usually had to delete his program and start again. For C, which has GOTO and structured loops, I've only used GOTO once, for clarity. From a certain perspective, needing "goto" is true, but only partially true. All loops, control flow, etc., must be reduced to "goto" or "gosub", since assembly only implements branches, jumps, calls, not higher level structured loops. (x86 assembly is an exception, but the structured loop constructs still aren't used...) So, from the perspective of assembly, goto's are used. But, from a different perspective, BASIC or C, GOTO's cause problems. They are unstructured. That means that a GOTO can branch out of one loop and into another, intentionally or accidentally. Since most loops have a loop variable or counter, this causes problems with a misplaced GOTO. The jumped into loop may not terminate correctly. Adding to the problem, early unstructured languages were line oriented. You could delete, insert, and renumber lines. But, you had to manually correct the changed line number in your GOTO's. I.e., you inserted line 32, had a GOTO from line 100 to line 35, after renumbering line 32 is 35 and 35 is 40, the GOTO still points to line 35, i.e., formerly 32, when it should point to 40. So, structured programming languages generally eliminate lines and line numbering. Code that is hard to follow or fix because of haphazard use of GOTO's is called "spaghetti code". Structured concepts fix this problem. They impose a few rules and hide the GOTO's behind other language constructs: FOR, DO-WHILE, WHILE, etc. Hiding GOTO's behind other language constructs makes sure the use of GOTO's follows the rules for structured programming. Structured programming generally requires a single entry and single exit from any procedure or loop. The C language usually allows multiple exits from it's procedures and loops. It's an exception when it comes to structured programming languages. C doesn't support multiple entry, but that can be simulated with constructs such as DUFF's device. However, C still has GOTO. This allows for easy porting of code from other languages. It's not needed to program. Using GOTO's in C, makes it *very* difficult to restructure the flow of the program. GOTO can be used for speed improvement to exit with many nested loops, but if the code was well written, the C compiler's optimizer will generate just as efficient code without GOTO's. It seems you stirred up the comp.lang.c, comp.lang.c++, crowds... I've removed them from this post. I'm not interested in hearing from them that my experience and knowledge is wrong. Rod Pemberton
From: bartc on 24 Apr 2010 20:32 spinoza1111 wrote: > On Apr 25, 12:27 am, "Daniel T." <danie...(a)earthlink.net> wrote: >> "bartc" <ba...(a)freeuk.com> wrote: >>> "Daniel T." <danie...(a)earthlink.net> wrote: >>>> 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. >>>> 90 x = 5 >> >>>> Now, I ask you, where is the line that was previously executed? Is >>> Goto's at least are usually confined to the same function >>> Most languages will allow "x=5" inside a function; where is that >>> function called from? >> As Dijkstra pointed out in "Go To Statement Considered Harmful" >> As soon as we include in our language procedures we must admit that >> a single textual index is no longer sufficient. In the case that a ..... >> Your comparison between functions and goto has already shown to be >> unfounded. > > Brilliant, couldn't say it any better. That's a shame, because I didn't understand a word of the Dijkstra extract. -- Bartc
From: Andrew Poelstra on 24 Apr 2010 20:54
On 2010-04-24, James Kanze <james.kanze(a)gmail.com> wrote: > On Apr 24, 1:20 pm, "Leigh Johnston" <le...(a)i42.co.uk> wrote: >> "spinoza1111" <spinoza1...(a)yahoo.com> wrote in message > >> news:051fa27d-5cf8-4f7e-94c8-e9e5b26566b7(a)g34g2000pro.googlegroups.com... > >> > On Apr 24, 6:06 pm, 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. > >> > Why not use break instead? Does the same thing, spares you >> > from having to define a label. > >> Because break only breaks out of the innermost loop, using >> goto to break out of nested loops is one of the few sensible >> uses of goto. > > But when do you have to break out of a nested loop? (And of > course, the only valid use of break in C++ is to end a case in a > switch. Otherwise, it's just a goto in disguise.) > [dropped alt.comp.programming and alt.lang.asm since my newsserver rejects an egregious number of cross-posts.] This is just as true in C, according to some people (myself included). The only exception I can think of is when you are looping only to set the loop index to something. ie, for(i = 0; i < 10; ++i) if(arr[i].state = READY) break; /* now use arr[i], or if i is 10, indicate failure. */ The alternative here, using the loop structure, would be: for(i = 0; i < 10 && arr[i].state != READY; ++i) ; /* now use arr[i], or if i is 10, indicate failure. */ To me, the latter option looks horrific, plus if you swap the operands of &&, you get a very hard-to-spot overrun. -- Andrew Poelstra http://www.wpsoftware.net/andrew |