on goto
in [ASM]
|
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: James Dow Allen on 24 Apr 2010 23:17 On Apr 24, 9:10 pm, "Daniel T." <danie...(a)earthlink.net> wrote: > ... > everyone who is tempted to argue about this issue to start from > Dijkstra's paper rather than simply asserting that "goto is good" > without understanding the issues involved. > > http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_ > Harmful.html I did click the link, though I'm sure I'd read the paper a few times earlier. It has one key sentence which I think is now widely understood: Edsger W. Dijkstra wrote: > The unbridled use of the go to statement has an immediate consequence > that it becomes terribly hard to find a meaningful set of coordinates > in which to describe the process progress. (Hmmm. Dijkstra *does* write "UNBRIDLED use of goto". Funny how that disappears from the pedants' sound-bite summaries.) Dijkstra speaks of "meaningful ... coordinates ... to describe ..." I think that when state machines are implemented with goto's, the goto *helps* to map such "coordinates": the transition rules move you to state 36 so you ... GOTO state39! One of my own goto's appears horrendous, but is actually just a way to go to the appropriate progress point when the "meaningful coordinates" have been established: Pseudo-code comparison http://fabpedigree.com/james/gotoalt.htm Actual C code http://fabpedigree.com/james/dbldum.htm (Warning: if anyone *does* say anything good about my code, it will be a first, and I'll probably faint from the exhiliration!) > http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_ > Harmful.html PS: Your newswriter seems to have clipped the link, Daniel, which I then had to hand-enter. I think Google Groups would have gotten it right, so you may want to switch to that: :-) > http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html James Dow Allen
From: James Dow Allen on 24 Apr 2010 23:22
On Apr 25, 10:17 am, James Dow Allen <jdallen2...(a)yahoo.com> wrote: > PS: Your newswriter seems to have clipped the link, Daniel, which > I then had to hand-enter. I think Google Groups would have gotten > it right, so you may want to switch to that: :-) Yes, Google's link did work. And yes, it was tongue-in-cheek of me to suggest you switch to Google. :-) Nevertheless I will point out that some pedants delight in ranting at every Google bug. When Google gets it right and their news software doesn't, they seem to view the non-Google foibles as "treasured souvenirs of a bygone superior era." :-) Just saying. |