on goto
in [General Programming]
|
From: Richard Heathfield on 11 May 2010 01:49 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 Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Phil Carmody on 11 May 2010 01:57 Seebs <usenet-nospam(a)seebs.net> writes: > On 2010-05-11, Keith Thompson <kst-u(a)mib.org> wrote: >> "Daniel T." <daniel_t(a)earthlink.net> writes: >>> Seebs <usenet-nospam(a)seebs.net> 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? > >>> I disagree. The obvious thing is to go through your list of MOB's and >>> see if any of them are foos. Your list of MOB's will likely be a 1D >>> vector or linked list. At most you have a list of MOB's per level and >>> even there, each level will be encapsulated. Essentially a recursive >>> algorithm. > >> What's a MOB? > > In many computer games, creatures are called "mobs" (short for mobiles, > because they can move). Down staircases are not usually mobile, and I was searching for the down staircase. > It's probably incorrect to turn it into block > caps, since the word did not originate as an initialism, but I could make > sense of it in context. (It's definitely incorrect to put an apostrophe > on the plural, though.) I think the ggpp was just trying to blag that he was familiar with the field in question, and therefore his view must carry more weight about implementation issues. Is there a commonly- named logical fallacy for misdirection through use of jargon? Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1
From: Phil Carmody on 11 May 2010 02:56 Richard Heathfield <rjh(a)see.sig.invalid> writes: > Willem wrote: >> Let's take your example to make my point: >> Richard Heathfield wrote: >> ) found = 0; >> ) for(x = 0; !found && x < xlim; x++) > No, the benefit of SESE is that you know that every loop has a single > entry point and a single exit point. It can exit after !found fails, or after x < xlim fails. Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1
From: Seebs on 11 May 2010 03:03 On 2010-05-11, Daniel T. <daniel_t(a)earthlink.net> wrote: > Seebs <usenet-nospam(a)seebs.net> wrote: >> What if "foo" isn't a "MOB"? What if "foo" is a kind of a thing of which >> there is no master list, just a list associated with each location? > Someone else is already beating you up on this one, so I'll just say > this... "What if the situation is exactly such that the best solution is > nested for loops and an early return?" To that I answer, then use nested > for loops and an early return. What is your point? My point is: In the case where that loop would have been written at all, the multiple-exit variant would be by far the cleanest solution. Every alternative provided has either been noticably more complex, or been reliant on an obviously-different data structure than the original addressed. I think in this case I'm pretty much in agreement with you on the issue; the correct thing to do is make a decision in each case based on the circumstances at hand. My objection is to having people invent things ("you look through the list of foos") which presume a wildly different data structure than had been suggested. > My observation is that people often get caught up working at much too > low a level than they should, and depending on what problem is being > solved, code like the nested for loop example we have been discussing is > indicative of that sort of thinking. That's a good point. I have certainly seen such loops which were indubitably a result of bad planning. I guess, offered as "this will necessarily work as a replacement", I find most of the replacements unappealing. Offered as "this is enough prettier that perhaps the data should be structured to suit it", many of them might be a step forwards... Depending, of course, on the specific data. -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:09
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 Heathfield <http://www.cpax.org.uk> > Email: -http://www. +rjh@ > "Usenet is a strange place" - dmr 29 July 1999 > Sig line vacant - apply within |