0xBaadF00d

Published June 26, 2006
Advertisement
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.
0 likes 14 comments

Comments

Programmer16
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].
June 26, 2006 08:13 PM
Sir Sapo
You should see the code for Angels 20, there's so many dangerous pointer things going on in there it boggles the mind...
June 26, 2006 08:59 PM
Stompy9999
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...
June 26, 2006 09:51 PM
Mushu
<3 teh stack.


(Oh, and boost::shared_ptr ftw! [wink])
June 26, 2006 10:04 PM
Stompy9999
Yeah, the best idea might be just to stop using raw pointers, at least for most things.
June 26, 2006 11:08 PM
Jesse Chounard
Yes, you should definitely use smart pointers.

But also, arrays are evil!
June 27, 2006 08:41 AM
Stompy9999
I was considering doing:
std::vector<std::vector<Tile_ptr>> tiles;

but decided not to. Maybe I should, though.
June 27, 2006 09:15 AM
Programmer16
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.)
June 27, 2006 09:56 AM
Rob Loach
Ahhhh, I miss the good old days of using the hack which is the C++ programming language....
June 27, 2006 12:03 PM
Metorical
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.
June 27, 2006 12:41 PM
Programmer16
lol, yea it is pretty ugly, but its all hidden from me in my Map class, so it doesn't bother me [smile].
June 27, 2006 04:14 PM
Will F
/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
June 27, 2006 04:56 PM
Stompy9999
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.
June 27, 2006 05:01 PM
Jesse Chounard
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.
June 27, 2006 10:31 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement