on goto
in [General Programming]
|
From: Nick Keighley on 11 May 2010 03:11 On 11 May, 06:49, Richard Heathfield <r...(a)see.sig.invalid> wrote: > Seebs wrote: > > Okay, here's a nice concrete case from code I've actually written once > > upon a time, or something much like it. > > > I'm working on a roguelike game. I have a dungeon, which consists of levels, > > and the levels are not necessarily all the same size. Each level is itself > > a 2D grid of points. It is quite conceivable to want to ask the question > > "is there any point in the dungeon which contains a foo". At this point, > > the obvious thing to do is > > for each level > > for each row > > for each column > > is there a foo? > > No, that's a terrible way to do it. > > You already have a list of foos, properly ordered for fast searching. > Search the list. > > If you don't already have a list of foos, then you are excusing one flaw > in your program by the existence of another flaw in your program. Two > bugs don't make a sensible programming strategy. Richard <no-name> [response to same post] **** If you were a complete idiot maybe. More sensible is to have a structure representing each game object as there are almost certainly less of them than squares on the grid. So it would be forall(game objects in this level) if its a foo .... **** good grief, they're agreeing...
From: Seebs on 11 May 2010 03:11 On 2010-05-11, Richard Heathfield <rjh(a)see.sig.invalid> wrote: > Bait away. My preference for SESE is rooted in some truly appalling SEME > code that I've had to maintain in the past. Having read posts by Mr. Nilges, why do you persist in using English, when it is clearly a language which supports apallingly bad writing? Which is to say: The fact that bad code can be written which can be fairly described as using multiple exits does not in any way establish that multiple exits are at fault. It is quite possible to write deeply illucid code which uses single exits. Multiple exits are not the underlying source of that problem, any more than C is at fault for all the atrocious C out there. C is very much a "here's the gun, here's your foot, do whatever you want" language. Sometimes you need this. Similarly, multiple exits certainly CAN create bad code... But sometimes that flexibility is needed to create the best possible code for expressing something clearly and/or evaluating it efficiently. Refusing to use them because someone somewhere used them poorly is silly. -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!
From: Seebs on 11 May 2010 03:13 On 2010-05-11, Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: > Seebs <usenet-nospam(a)seebs.net> writes: >> Because the test conditions aren't part of the standard "loop over array" >> idiom, I have to track both parts of the test condition separately, and doing >> that for three layers of looping chews up six short-term memory slots, and >> the index variables use up three more, leaving me solidly past my short-term >> memory budget without even looking at the inner loop. For the form using >> the pure idiom, I'm only using three slots -- I have x, y, and z as "the >> current indexes in the loop". > There's a 4th slot in use. It's > three trivial loops and one trivial special case > versus > three non-trivial loops > I agree that I view the former as simpler, (but am more likely > to be a break-user than a return-user). I was thinking about what I have to have in mind when I'm looking at the contents of the inner loop. The trivial special case *is* the contents of the inner loop -- it's no worse in complexity than the "found = 1" or similar trait that some SESE advocates have proposed. In the case of the "return a pointer to a[x][y][z]" function, I actually rather liked using the pointer itself as the test-for-done, although I'm not sure whether I should. In general, though, I've been using if (p) long enough that a pointer is always comfortable for me as a boolean; either it points or it doesn't. -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!
From: Seebs on 11 May 2010 03:08 On 2010-05-11, Richard Heathfield <rjh(a)see.sig.invalid> wrote: > Seebs wrote: >> I'm working on a roguelike game. I have a dungeon, which consists of levels, >> and the levels are not necessarily all the same size. Each level is itself >> a 2D grid of points. It is quite conceivable to want to ask the question >> "is there any point in the dungeon which contains a foo". At this point, >> the obvious thing to do is >> for each level >> for each row >> for each column >> is there a foo? > No, that's a terrible way to do it. > You already have a list of foos, properly ordered for fast searching. No, I don't. Why are you running a binary search on this specific array to see whether an integer is found in it? You already have a list of integers, properly ordered for fast searching; just run through that list and then find out which array the integer you want is contained in. .... or don't. > If you don't already have a list of foos, then you are excusing one flaw > in your program by the existence of another flaw in your program. Two > bugs don't make a sensible programming strategy. I disagree. It is not at all obvious that "foo" is necessarily a type of thing that ought to have a central list. When doing a model of a world, it is quite often the case that there are many hundreds of types of objects which might exist, and each location has a list of the objects it contains. A single centrally sorted list of all the objects of each type would be ludicrous. A single centrally sorted list of all the objects which exist anywhere would be of extremely marginal utility. In particular, for the case of, say, a roguelike game which includes multiple dungeons, searching a given dungeon (using the nested loop) would be orders of magnitude faster than searching a complete list of every object stored anywhere in the game. In short: It depends. There exist problem spaces for which a nested search really is the right tool. There exist others for which it isn't. Dogmatically asserting that every problem for which a nested loop is the best solution exists only because of some other arbitrary flaw is pointless. We might as well point out that English is absolutely the clearest and most expressive language, because anyone who wants to say something which is not most clearly expressed in English is clearly saying something stupid. -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!
From: Nick Keighley on 11 May 2010 03:27
On 10 May, 18:36, James Dow Allen <jdallen2...(a)yahoo.com> wrote: > On May 11, 12:03 am, Seebs <usenet-nos...(a)seebs.net> wrote: > > On 2010-05-10, Richard Heathfield <r...(a)see.sig.invalid> wrote: > > > Seebs wrote: [seebs early exit] [heathfield strict Single Exit] > Well at least Heathfield and Seebs agree on *something*: > We seek human cognitive advantage. > > The specific code being debated, IIRC, does *not* even involve > goto's (*Please change the subject lines, people*), but is > rather a trivial search through a 3-D array: > for ... > for ... > for ... > if ... return; > In fact the code was so straightforward one might wonder why > alternatives were even being proposed. too right... > I did not search the > thread rigorously; I noticed one code by Nathan(?) which > seemed obviously inferior. I gather C++ afficionados are > proposing a new "access method" for such 3-D arrays (I find > for...for...for much too easy to understand, especially since > the full package will probably be doing this *many* places > needfully, for an a priori unfamiliar method to be useful). > Mr. Heathfield, IIRC, hasn't actually deigned to post an alternative. I think he proposed for (loop_incomplete OR not_found) for (loop_incomplete OR not_found) for (loop_incomplete OR not_found) if ... found <- T that is an extra boolean (and some extra testing) > (Contrary to some beliefs I wrote my favorite goto in a smallish > fraction of a day; to claim you don't have time to rewrite > for for for if return ... well... :-) > > The thread title is "Goto" but break, inside return, and > switch fallthrough suffer, to smaller extent, the same sin as > goto. no, not really. Early exit isn't goto. > We read > On Apr 29, 3:20 pm, Tim Rentsch <t...(a)alumni.caltech.edu> wrote: > > Keith H Duggar <dug...(a)alum.mit.edu> writes: > > > > Subsequently I discussed that flame war with one of the worlds > > > genius compiler writers who confirmed the necessity of the inlining > > > etc controls explained above. However, he also added that in his > > > experience it is pointless to argue with the anti-goto mob because > > > it is a religion that ignores all inconvenient empirical evidence. > > . > > Essentially the same thing could be said of the pro-goto mob. I rather be referred to as the Early Exit Mob > Wrong. The anti-goto mob claims to prefer code that > is clearly more complex well they don't accept your premise. Though I think abusing C's overly complicated for-loop constuct is well on the road to ruin. {turing over another rock and finding a can of worms] > (is Nathan's the best you have? > Did you ever post your solution, Mr. H?) in order to avoid the > inside return (or goto). None of us are "pro-goto" per se; we're > just asking to *look at all the code and make the best trade-offs*, I think everyone's claimign to be doing that. Unless someone wants to pay the cognitive scientists to do their stuff we're stuck with "well, MY way is OBVIOUSLY better" reiterated. > or select the "least of evils." It's usually better to introduce > 1 or 2 boolean variables than to write goto, or return or break? > but what if it's 3 > variables and you still need a break? What if by using switch > case-fallthrough's you save the need for 5 little functions? ah, sometimes the 5 little functions are good. Fowler "Refactoring" > There is no "universal demerit system" for code complications, > but to assign inside-return a cost of infinity seems much > too aggressive. yes. That's nearly a keeper -- But ye have set at nought all my counsel, and would none of my reproof: I also will laugh at your calamity; I will mock when your fear cometh; [Proverbs 1:25] |