Bug hunt

It sounds like you have free''d the array of pointers, and then dereferenced them to free the rows. This is a nasal deamon, another guess is that the sound code is grabbing the newly free''d memory before you dereference, and thats why it''s breaking now. It was likely always broken, it just happened to work.

Going out on a limb here, you are using this so you can say grid[x][y] somewhere aren''t you? What is the fasination with this construct? Everyone is bending over backwards to avoid saying grid[y*width+x] WHY??????? How do you suppose the compiler does grid[x][y]? if you have char[8][8] the comiler can resolve this to grid[y<<3+x], so that''s faster. But with a dynamic array you have to dereference, fetch, dereference, fetch to get your value. You also have lost locality of reference and wasted Y pointers. C++ people also do vector < vector < T > > all the time. Then they use a fixed width and height.

I always thought they should just let you overload the [] operator with more than one parameter, giving you a BASIC-/Pascal-like reference (ie, grid[8,4], space[50,1,24], etc.). Not that I''m much for BASIC or Pascal anymore, but I always found that much easier than grid[8][4]. Usually, I just make an object with an inline member function Index(int x,int y,etc.) that does the same thing. *shrug*

Here''s something for some abstract physics: char& operator[](int x, ...);

quote:

---

Original post by SkyDruid

I always thought they should just let you overload the [] operator with more than one parameter, giving you a BASIC-/Pascal-like reference (ie, grid[8,4], space[50,1,24], etc.). Not that I''m much for BASIC or Pascal anymore, but I always found that much easier than grid[8][4]. Usually, I just make an object with an inline member function Index(int x,int y,etc.) that does the same thing. *shrug*

Here''s something for some abstract physics: char& operator[](int x, ...);

---

Yeah, that would be the way to go, the let you call it with strings for assoiative objects, so your already abusing the syntax. One trick is to have an index class, or a heiarchy with some classes forceing powers of 2. Then you define () and at() where at does bounds checking and throws exceptions. Each just returns size_t = wh*Z+w*Y+X, with shifts in the pow2 variant. It s then trivial to either compose a class with a data pointer and index, or use it as a utility class. Good tradeoff between programmer/program optomisations.

grid[CIndex2(8,8)(3,4)] might look horrid, but it actually compiles fairly tight. grid[I(3,4)] is beter and it becomes easy to write functions of the form f(const Index2 &I, char *data); It sometimes makes sense to break the expected encapsulation, even though we have no assurance that *data points to a region of the correct size.