on goto
in [General Programming]
|
From: Richard on 10 May 2010 19:56 "Daniel T." <daniel_t(a)earthlink.net> writes: > Seebs <usenet-nospam(a)seebs.net> wrote: >> On 2010-05-10, Daniel T. <daniel_t(a)earthlink.net> wrote: >> >> > Why shouldn't I assume that the data are contiguous? >> >> Because there's nothing saying they are... > > There is nothing saying anything at all. > >> > In what context is a short-circuit linear search appropriate through >> > a 3-D ragged arrayed container? Just because that's the way you want >> > it so that you can stand on your soapbox and say, "see I told you >> > so"? >> >> 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? > > 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. > > for each level > is there a foo? > > I ask again, what is your goal in continuing this thread? What is it you > are trying to get me to admit to that I haven't already admitted Sorry. you had already answered. See my other reply to Seebs. Seebs is simply not a very good programmer and likes to waffle on about ISO C rather than finding optimised solutions to real programming issues as his "obvious solution" above demonstrates .... -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c
From: Richard on 10 May 2010 19:55 Seebs <usenet-nospam(a)seebs.net> writes: > On 2010-05-10, Daniel T. <daniel_t(a)earthlink.net> wrote: >> Why shouldn't I >> assume that the data are contiguous? > > Because there's nothing saying they are, and making an assumption without > any support beyond "this would make my code simpler" seems counterproductive. > >> In what context is a short-circuit >> linear search appropriate through a 3-D ragged arrayed container? Just >> because that's the way you want it so that you can stand on your soapbox >> and say, "see I told you so"? > > 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? > > -s 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 .... -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c
From: Keith Thompson on 10 May 2010 20:03 "Daniel T." <daniel_t(a)earthlink.net> writes: > Seebs <usenet-nospam(a)seebs.net> wrote: >> On 2010-05-10, Daniel T. <daniel_t(a)earthlink.net> wrote: >> >> > Why shouldn't I assume that the data are contiguous? >> >> Because there's nothing saying they are... > > There is nothing saying anything at all. Then why are you assuming anything? >> > In what context is a short-circuit linear search appropriate through >> > a 3-D ragged arrayed container? Just because that's the way you want >> > it so that you can stand on your soapbox and say, "see I told you >> > so"? >> >> 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? > > 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? > for each level > is there a foo? And how do you ask whether there's a foo on a given level? [...] -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Lew Pitcher on 10 May 2010 20:08 On May 10, 2010 20:03, in comp.lang.c, kst-u(a)mib.org wrote: > "Daniel T." <daniel_t(a)earthlink.net> writes: [snip] >> for each level >> is there a foo? > > And how do you ask whether there's a foo on a given level? ... struct fooType *thisFoo = fooRoot; ... while (thisFoo != NULL && thisFoo->level != target_level) thisFoo = thisFoo->nextFoo; if (thisFoo == NULL) return NO_FOO_ON_LEVEL; else return FOO_FOUND_ON_LEVEL; HTH ;-) -- Lew Pitcher Master Codewright & JOAT-in-training | Registered Linux User #112576 Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/ ---------- Slackware - Because I know what I'm doing. ------
From: Seebs on 10 May 2010 20:48
On 2010-05-10, Daniel T. <daniel_t(a)earthlink.net> wrote: > Seebs <usenet-nospam(a)seebs.net> wrote: >> On 2010-05-10, Daniel T. <daniel_t(a)earthlink.net> wrote: >> > Why shouldn't I assume that the data are contiguous? >> Because there's nothing saying they are... > There is nothing saying anything at all. Good reason not to start adding unsupported assumptions, then. You should not assume that they are contiguous, or that they aren't; you should write code that will work either way unless you have information saying otherwise. >> 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 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? Not a purely theoretical question here; in the roguelike I did, this was basically the case for a number of things, such as items. Each creature had a list of items it was holding. There did not exist, anywhere, a master list of items. Or a master list of creatures. Locality of reference FTW... As long as you don't need to do a search like that. :) > I ask again, what is your goal in continuing this thread? What is it you > are trying to get me to admit to that I haven't already admitted? You didn't ask me that, you asked someone else that. I guess I'm just pointing out that all of the "simplifications" I've seen have been simplifications which relied on massive and unsupported assumptions, and more importantly, assumptions which are wrong often enough for it to be a serious problem. There is no general expectation that multidimensional data structures are contiguous in memory in C; it is much more common for them to consist of numerous allocated regions which are non-contiguous. -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! |