Reliability of C++

[Flikerator]

Has anyone ever had a working C++ program, then closed it, opened it later, and then without changing it, had it crash?

I have two for loops;

code:

for (int i=0;i<40;i++) {          for (int j=0;j<30;j++) {              gridIDs[i][j]=0;              gridDens[i][j]=0;          }      }

And it crashes. I remove this code, it's fine. The for loops seem fine, because I take out the two var declarations, and its fine. I just fixed an error before I closed down my dev project (Using Dev C++ Bloodshed, btw) where I typed "40" for j instead of "30".

Sometimes it crashes completely. Sometimes it works, and then when I escape (Its a fullscreen program) the resolution doesn't change back, and I have to actually alt+ctrl+del to close it. Sometimes it will work completely, and when I exit, Dev won't let me run it again until I program reset (Alt+F2).

I'm not really asking for help, just wondering if people experience this kind of thing with C++? I heard it was very common, which is why I decided to do some C++. Helps to get debugging skills for any language one might encounter


[EDIT:1]

Okay so this seems like a conundrum. The problem is these two arrays:

code:

int gridDens[39][29]; int gridIDs[39][29];

So I decided to make another array, identical except for name:

code:

int newArray[39][29];

I commented the other two assignments, and put in this one; presto it works.

code:

for (int i=0; i<40; i++) {          for (int j=0; j<30; j++) {              newArray[i][j]=0;              //gridIDs[i][j]=0;              //gridDens[i][j]=0;             }      }

If you can see something there that suggests why it fails I'd be happy to hear it, because I'm perplexed. They are all declared under the class header file under "private" and only accessed this one time. (I commented other usages to find the problem). Why the previous code works, and this fails:

code:

for (int i=0; i<40; i++) {          for (int j=0; j<30; j++) {              newArray[i][j]=0;              gridIDs[i][j]=0;              //gridDens[i][j]=0;             }      }

Really makes me think. I tried deleting the .o files, nothing. I tried deleting the .exe even; nothing. I wasn't really asking for help before, but if anyone knows why this might be happening let me know, it seems pretty tricky to me.

[Clayton]

Whee! Let's make random memory locations be equal to 0!

[Mazer]

Clayton @ Tue Aug 28, 2007 12:03 am wrote:

Whee! Let's make random memory locations be equal to 0!

Random? Maybe I'm missing something, but it looks like everything is within bounds.

@Flikerator: Are you sure that segment of code is where the crash is happening?

[andytyk]

Remember, array indexes start at 0. So you're trying to fill a 40x30 array when you've only declared memory for a 39x29.

[CodeMonkey2000]

@andytyk look closer at the code, he has already resolved that problem.

@Flikerator I get no error. can you please post your entire code?

[Clayton]

Mazer @ Tue Aug 28, 2007 7:39 am wrote:

Clayton @ Tue Aug 28, 2007 12:03 am wrote:

Whee! Let's make random memory locations be equal to 0!

Random? Maybe I'm missing something, but it looks like everything is within bounds.

@Flikerator: Are you sure that segment of code is where the crash is happening?

I could've swore I saw something different this morning... I'll use me being extremely tired as an excuse for that one.

[McKenzie]

I don't know what the [EDIT:1] refers to but the error that Andy pointed out is still there.

[Mazer]

Damn off-by-one errors. I'm feeling stupid now. Yeah, 0 to 39 would mean 40 iterations. It was staring me right in the face and I kept thinking "no, it's ok because it's going up to one less than 40".

I don't know exactly what your program is doing, but this seems like it could be a nice place to use constants rather than hardcoding values.

[Flikerator]

I'll zip the code, since its 5 files, and then images. If I have any bad coding practices, feel free to beat me over the head

Oh, and you need the Allegro package. I downloaded it on Dev c++ Bloodshed, but you can [url="http://www.talula.demon.co.uk/allegro/wip.html"]get it here[/url].

I'll include the...Oh crap, I commented the "newArray" portions, and uncommented the rest, and it works now...

Ha, Clayton's first post actually made me think of it. When I loaded it up, I had rand() % 2 as a declaration instead of 0 (I added a second tile, so I figured, well lets have random green or brown tiles, the chicks would love it). However, when I was getting rid of the things to find the error, the rand part was the first. It still gave the error, so I didn't think of it. However, I added it again now and it failed. I erased the change, and it failed. There is not one scrape of rand, yet it still fails.

My guess: Something goes wrong when it tries to assign rand() % 2 in the memory, and the memory isn't freed when the program ends; instead it uses the same locations for memory allocation, or something, which have been corrupted. Even reseting Dev does nothing, even with it saved after rand() has been removed. The only thing that fixes it, that I'm aware of, is shutting down and starting back up, which clears the memory.

However, if I remove the code where gridIDs and gridDens are being made into 0, it loads as if I declared them as 0 (ie, loading the first tile on the screen). So maybe any changes to the memory have been corrupted, but the memory itself is fine...? Since it's still there, but can't be changed.

Ahh, another 'discovery'. I had only used rand() % 2 on gridDens this time. I haven't used the density (collision) yet, so I simply commented it, and it worked. So the problem was made by rand(), I assume. The reason? I didn't include the stdlib.h package (if thats the right term). That is again, just a guess.

I don't care what anyone says, C++ is a lot of fun! I either do it right and it works, or I screw up and I am awarded hours of bug catching (not being sarcastic).




For the file:

To mess it up, simply take out the #include <stdlib.h> line. Run it, and as the chef says, "Bam!", it should fail. (You might want to run it without changing first, just to see that it works).


@McKenzie: The [Edit:1] was just the first edit I made, which is everything after that. Originally it was just a short post before I edited it.

[md]

Did you know that the number in the []s when you declare your array is the size, not the upper bound?

Since you want a 40x30 array you declare it array[40][30], and the indecies will be 0-39 and 0-29 respectively. What you got there is a nice big out-of-range error.

Good to see everyone else missed it.

[edit]

The reason it didn't crash when you added another array is probably because the writes beyond the range of your arrays then ended up in the memory reserved for the third array. It's very difficult to confirm this however as compilers can move bits of your code around (and change the order variables are declared) for their own purposes.

[Mazer]

md @ Wed Aug 29, 2007 12:21 pm wrote:

Good to see everyone else missed it.

Good to see that you missed that not everyone else missed it.

[md]

Shh! I can't be expected to read the entire thread! Especially since the last post by the OP seems to show hte problem hasn't been solved.

Clearly he didn't read the replies either.

[Cinjection]

If you're using arrays, in C++, you should make a little wrapper for a generic array (using templates) and then overload the indexing operators ( [] ). This will let you use your array like any other, only yours will contain some sort of bounds checking.

[md]

there is already such a thing: std::vector

[Cinjection]

md @ Sat Sep 01, 2007 1:04 pm wrote:

there is already such a thing: std::vector

Indeed, but vector contains a lot of extra functionality that one might not need for a basic array use. This array wrapper would only need to overload the = and [] operators, as opposed to the STL's vector which provides a lot more functionality, that sometimes isn't needed and just adds overhead.