• entries
686
1952
• views
386444

151 views

Looking at the title, I bet most of you know what this entry will be about.

I have to say, first off, that I'm loving working on this project, because I'm learning so much. Such is the case with pointers. I consider myself pretty inexperienced when it comes to using them, so I'm always learning something new. Ofcourse, my programs have to crash 20 times before I learn the lesson[lol]

Today, I was writing some of the code for the grand overworld map. I realized that I'm not going to have the town be a seperate map, but rather a sub-map within the larger map of the world. Anyway, I had to write a routine that would iterate through the tile array, find any uninitialized tile pointers, and initialize them to the generic grass tile. So, I wrote the following code:

for(int i = 0; i < height; i++)    for(int c = 0; c < width; c++)        if(tiles[c] == NULL)           tiles[c] = new Grass();

Pretty confident in myself, I went and compiled the program, and it compiled just fine(that's not entirely true, but besides the point). However, the program crashed over, and over, and over again.

Now, I always wondered when looking at C++ code, why do people bother to initialize a pointer to NULL. Surely the pointer must already be set to NULL by default! Oh, how naive I am.

Long story short, I learned this lesson the hard way, but eventually fixed the problem. Now I've learned the fairly obvious lesson, you actually have to initialize a pointer to NULL to compare it to NULL.

Anyway, I'm pretty anxious to get the player code working so I can walk around in the game world.

If you're using VS2005 Express then you can modify the code formatting in the editor options. If you're not using Express, well then I guess it sucks to be you [razz].

You should see the code for Angels 20, there's so many dangerous pointer things going on in there it boggles the mind...

That's why I feel uncomfortable using so many pointers in my code. It feels like any second it could just crash.

Then again, the alternative isn't much better either...

<3 teh stack.

(Oh, and boost::shared_ptr ftw! [wink])

Yeah, the best idea might be just to stop using raw pointers, at least for most things.

Yes, you should definitely use smart pointers.

But also, arrays are evil!

I was considering doing:
std::vector<std::vector<Tile_ptr>> tiles;

but decided not to. Maybe I should, though.

Quote:
 Original post by Jesse Chounard Yes, you should definitely use smart pointers. But also, arrays are evil!

Where did you get an idea like that? I agree that 2D arrays are evil, but a container is no less evil than a single-dimension array other than it MAY have bounds checking.

@Stompy - I'd recommend just doing a single-dimension array of map-row-count * map-column-count. If you want to implement layers then fake it. For example:
MapColumnCount = 25;
MapRowCount = 19;
MapLayerCount = 3;

for(int nLayer = 0; nLayer < MapLayerCount; ++nLayer)
{
for(int nRow = 0; nRow < MapRowCount; ++nRow)
{
for(int nColumn = 0; nColumn < MapColumnCount; ++nColumn)
{
int nCurrentTile = ((nRow * MapColumnCount) + nColumn) + ((MapColumnCount * MapRowCount) * nLayer);
// lol, I'm pretty sure that's right, but I'm not positive.
// It's something like that.
}
}
}



Although, a vector would work, IMHO it's overkill.

The rule I go by (which, obviously, is my opinion) is only to use vectors to store lists of items (list as in it can get longer or shorter at any time) and to use arrays to store constant blocks (data that stays the same size.)

Ahhhh, I miss the good old days of using the hack which is the C++ programming language....

I disagree with Programmer16 because the logic is more convoluted and you don't really gain any safety.

You could build your own container and even overload operator [] so that it behaves like your 2D array. There's also a thousand ways you could represent the data internally. You may want to do something like Programmer16's code in here and then expose a nicer interface.

lol, yea it is pretty ugly, but its all hidden from me in my Map class, so it doesn't bother me [smile].

/me points in the direction of boost::array, which is part of TR1 (more info here), and AFIAK will be part of the next C++ standard.

/me also points in the direction of boost::multi_array

Well, in reality, the maps are stored as objects called "Zones". If a zone object is interacted with outside of the object, it has a pretty nice interface. However, what I posted was some of the internal loading code.

Also, although I don't show it here, the Zone class does have bounds checking on the tile array.

Quote:
 Original post by Programmer16 Where did you get an idea like that?

Didn't you read the link you quoted me writing about? It gives some very clear reasons of why arrays are evil.

Quote:
 The rule I go by (which, obviously, is my opinion) is only to use vectors to store lists of items (list as in it can get longer or shorter at any time) and to use arrays to store constant blocks (data that stays the same size.)

I disagree strongly with this. But that's not necessarily important, as Stompy's maps should (IMO) not be constant sized. And if you're going to choose your array size dynamically, it is very unlikely you'll implement it better than std::vector.

## Create an account

Register a new account