on goto
in [General Programming]
|
From: Daniel T. on 10 May 2010 18:09 brangdon(a)cix.co.uk (Dave Harris) wrote: > daniel_t(a)earthlink.net (Daniel T.) wrote (abridged): > > > > > I would be interested in code that solved the same problem that > > > the original code solved. Or are you agreeing that the original > > > code was the best, for that problem? Can you only do better if you > > > change the problem by adding extra invariants? > > > > Am I adding extra invariants? I don't know what the invariants are, > > and I have no reason to believe that the code presented solved any > > problem at all. > > > > That's part of the point I'm trying to make here. We have been > > handed an incomplete solution to a nonexistent problem and you are > > asking me if I could write code that "solved the same problem..." > > Here you go: > > > > int main() { } > > > > My example above has the benefit of actually being able to compile > > and run. You can't do that with the original example. > > The original code was: > > Value_t* MyClass::findValue(const Value_t& value) > { > 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 you are truly saying you don't understand what problem this code is > trying to solve, to the point where you claim "int main() { }" is > solving the same problem, then I have trouble believing you are > debating in good faith. How can your code comprehension skills be so > poor? > > If it helps, I'll add some code. > > #include <vector> > > using namespace std; > typedef int Value_t; > typedef vector<Value_t> z_vec; > typedef vector<z_vec> y_vec; > typedef vector<y_vec> x_vec; > > struct MyClass { > x_vec data; > > void test(); > Value_t *findValue( const Value_t& value); > }; > > int main() { > MyClass().test(); > } > > void MyClass::test() { > findValue( 0 ); > } > > Putting this in front of the original code is enough to make it > compile. Any competent C++ programmer could have come up with it. I'll > let you write some code to initialise MyClass::data from stdin > yourself. If you are truly incapable of doing that, then I have to > question whether your opinions are worth any weight at all. (I don't > need to see the code. I just want you to stop being obtuse, when you > clearly know better.) > > There are other ways to define data etc so that the original code > compiles. It shouldn't be necessary to assume more about the problem > than what the original code gave us, which was basically operator[] > and size() as used. That was enough for the original code. Alternative > solutions ought to work with any reasonable definitions, including > this one. > > You shouldn't assume that the data are contiguous, or that someone > else will write a convenient magic iterator for you. Once again, you pile on a bunch of code without specifying the problem it's supposed to solve, then you challenge me to provide code that will better "solve the problem." I ask again, what problem? Why shouldn't I assume that the data are contiguous? 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"? What is it you are trying to prove? If all you want is for me to say that sometimes multiple returns are the best solution... I've already done that, otherwise explain yourself better.
From: Seebs on 10 May 2010 18:52 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 -- 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: Daniel T. on 10 May 2010 19:30 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?
From: Ben Bacarisse on 10 May 2010 19:56 Seebs <usenet-nospam(a)seebs.net> writes: > On 2010-05-10, Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote: <snip> >> You can't assume that the data is contiguous or, to be a little more >> general, that a single [] operation means the same as three of them. >> This is, after all, C++ not C. > > In C++ it's at least conceivable that someone could come up with some > exceptionally sneaky overloading of [] to make it viable. That's why I said "you can't assume...". It is conceivable but it is not a sensible assumption for the poster[1] to make. The post was about a re-write to simplify come code. If that involves a "sneaky overloading of []" any argument about simplification is blown away. [1] Was it Nathan? All earlier attributions have gone. -- Ben.
From: Dann Corbit on 10 May 2010 19:57
In article <daniel_t-BE382C.19303110052010(a)70-3-168- 216.pools.spcsdns.net>, daniel_t(a)earthlink.net says... > > 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? Are you really unable to conceive of a data structure with more than one dimention? I suggest that a web search for the terms "octree" and "quadtree" may prove interesting to you. See, for instance: http://en.wikipedia.org/wiki/Octree http://en.wikipedia.org/wiki/Quadtree I would be very keen to see a data structure that can model weather on the surface of the earth and which does not consist of many levels (besides spherical coordinates, we have elevation, temperature, pressure, humidity, wind direction, wind velocity, etc.) See, for instance, NCAR: http://ngwww.ucar.edu/ |