on goto
in [General Programming]
|
From: Kenneth Brody on 28 Apr 2010 09:37 On 4/27/2010 10:07 AM, Richard Bos wrote: > "Daniel T."<daniel_t(a)earthlink.net> wrote: > > [ Quoting Dijkstra's "Goto considered harmful": ] > >> The unbridled use of the go to statement > > This is the one thing which Dijkstra's editor (who wrote that headline), > the War-On-Goto lobby, and even Dijkstra himself in later years, seem to > have missed. > > _Unbridled_. > > The unbridled use of salt is also deadly to humans. We must ban it > outright. I thought that "on goto" was part of BASIC, and not C or C++. <gdrc> -- Kenneth Brody
From: Lie Ryan on 28 Apr 2010 11:02 On 04/25/10 01:18, Richard wrote: >>> but it is a good opportunity to suggest to >>> 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 >> >> And then read Knuth's "Structured Programming with go to Statements" (a bad >> scan is here: >> http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf) >> >> "... programmers and language designers still feel the need for some >> euphemism that 'goes to' without saying 'go to' ..." > > Recommending Knuth is like telling someone they need to qualify as a > NASA rocket scientist in order to fly a kite. The Japanese thought so: Ikaros "Interspace *Kite*-craft Accelerated by Radiation of Sun" http://www.news.com.au/technology/ikaros-space-yacht-ready-to-sail-as-far-as-sun-shines/story-e6frfro0-1225859168363
From: gwowen on 28 Apr 2010 11:22 On Apr 28, 12:19 pm, Juha Nieminen <nos...(a)thanks.invalid> wrote: > Or in less words: "What's the simplest way of exiting nested loops?" > You simply attempted to evade that question by nitpicking on irrelevant > details of the example code. Juha Nieminen, meet Richard Heathfield.
From: Alexei A. Frounze on 28 Apr 2010 11:52 On Apr 28, 2:13 am, Richard Heathfield <r...(a)see.sig.invalid> wrote: .... > Probably true. The problem is rather like that of threading vs state > machines. State machine advocates claim that threading is for people who > can't write state machines, and threading advocates claim that state > machines are for people who can't understand threading. How's that? I think some problems can't be solved (at all or easily) with one of the two. And at times both are necessary. Alex
From: Seebs on 28 Apr 2010 13:09
On 2010-04-28, Richard Heathfield <rjh(a)see.sig.invalid> wrote: >> { >> for(size_t xInd = 0; xInd < data.size(); ++xInd) >> for(size_t yInd = 0; yInd < data[xInd].size(); ++yInd) >> for(size_t zInd = 0; zInd < data[xInd][yInd].size(); ++zInd) >> { >> if(data[xInd][yInd][zInd] == value) >> return &data[xInd][yInd][zInd]; >> } >> >> return 0; >> } > If the data are sorted, bsearch. > If not, why not? I do not normally expect something structured like a three-dimensional array to be sorted, I expect it to be a representation of objects. > In any case, your loop condition expressions do not correctly describe > the conditions under which the loop will terminate. Please rewrite your > example so that they do, and then by all means ask me again if you wish. I think the point was that he was asking *you* to rewrite the example so that the loop conditions correctly describe the conditions under which the loop will terminate. I put it to you that it is impossible to write the above loop with remotely comparable clarity without using a jump of some sort out of the inner loop. Any attempt to do so will result in a MASSIVE loss of clarity. * You can't refer to yInd and zInd from the outer loop unless you declare them outside those inner loops, but doing that is undesireable, because loop indecies should ideally be declared with their loops and used only in those loops. * Until you've started the inner loops, you can't refer to the innermost value, and as such, you can't write that comparison. * Adding an extra test to every level of the loop creates extra computational time and makes things more confusing. The best approximation I can think of is to do each of these as a separate function, but even that doesn't let us avoid either some kind of break/return, or adding a "found" value. In short, this is a case where dogmatism about single-entry/single-exit has very high costs to clarity. Now, it may be that it's worth it because of the net gains in clarity and consistency elsewhere, but this certainly is one of the worst cases for it. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! |