on goto
in [General Programming]
|
From: spinoza1111 on 25 Apr 2010 04:09 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"? Return exits the containing function and has its place, certainly, under abnormal conditions. But break goes to the statement following the loop and is considered acceptably structured in reality, because it can be so readily simulated as I've shown using a flag. > > "It's not the same thing". Precisely. If you design your code such that > you can always use 'return' to break out of nested loops, it will become > cleaner and easier to understand. > > I have been programming in C++ both professionally and as a hobby for > over 10 years, and I have never got into a situation where 'goto' would > have been a tempting alternative because of being a simpler and more > straightforward solution than something else. It just doesn't come up. > I don't remember ever having written a 'goto' in the last 10+ years. > > It's not a question of banning 'goto'. There is no *need* for 'goto'. > And if you code in such way that you just don't need it, your code will > become cleaner in a completely natural way.
From: io_x on 25 Apr 2010 04:31 "Rod Pemberton" ha scritto nel messaggio > "io_x" <a(a)b.c.invalid> wrote in message > Structured programming generally requires a single entry and single exit > from any procedure or loop. it should be for one loop one single entry but one or more exits [at last for error code "more exits"] > 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. they not understand that all with goto is easy, easier than their difficult way of describe one algorithm, and more flexible
From: Bo Persson on 25 Apr 2010 04:51 Seebs wrote: > On 2010-04-25, Andrew Poelstra <apoelstra(a)localhost.localdomain> > wrote: >> I often see code like > >> if(setup1() == 0) >> goto fail; >> >> if(setup2() == 0) >> goto fail; >> >> if(setup3() == 0) >> goto fail; >> >> /* now do stuff */ >> >> return 0; >> fail: >> /* :( */ >> return 1; > >> Personally, I would do this as: >> >> if(setup1() && >> setup2() && >> setup3()) { >> /* now do stuff */ >> return 0; >> } >> else { >> /* :( */ >> return 1; >> } > >> But from a stylistic view, the first version doesn't seem all >> that bad. I see it a lot and it doesn't bother me, anyway. > > It gets worse when there's non-trivial work which needs to be done > between the various setup(), and/or they have to interact with more > than one or two local variables. There's also the fairly common > idiom: > > if (setup1()) > goto fail; > > if (setup2()) > goto teardown1; > > if (setup3()) > goto teardown2; > > /* various stuff */ > if (something_went_wrong) > goto teardown3; > /* more stuff */ > > teardown3: > teardown3(); > teardown2: > teardown2(); > teardown1: > teardown1(); > fail: > return -1; > > This has the advantage that, if later you need to add a setup2_5(), > you don't have to go to multiple different places later in the code > and add a teardown2_5(). > > In general, I find that overly dogmatic structuring tends to reduce > readability. The "obvious" alternative to the above: > > if (!setup1()) { > if (!setup2()) { > if (!setup3()) { > /* various stuff */ > if (!something_went_wrong) { > /* more stuff */ > } > teardown3(); > } > teardown2(); > } > teardown1(); > } > > is, IMHO, less readable and less maintainable. It's harder to track > where you are by looking at indentation, and there's less room on a > default-width screen for writing clear code inside /* more stuff */. > > -s Guess why C++ added destructors to automatically destroy objects that go out of scope. Sorry, couldn't resist. :-) Bo Persson
From: Alexei A. Frounze on 25 Apr 2010 05:20 On Apr 24, 5:18 pm, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote: .... > 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. We can misplace and incorrectly reorder many things, not just goto's. 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. Alex
From: Alexei A. Frounze on 25 Apr 2010 05:49
On Apr 24, 5:18 pm, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote: > 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. Stay away from purists and idealists, they are far too often too strict and offer impractical advice. :) I too have been bitten by those folks. That's not to say I didn't learn anything from the experience -- I spent quite some time figuring out proper C as per its standard and started coding more portably and defensively (but that's a totally different story). Alex |