MS Visual C++: stack overflow when calling function

[Structural Integrity]

What is the problem here? It's a simple function of a simple object. If I call another function of the same object it works fine, but that function messes up:

terrain.loadTerrain("terrain.raw");

bool CTerrain::loadTerrain(char* filename)
{          //it doesn't even come here
	unsigned char terra[TERRAINSIZE*TERRAINSIZE];
	FILE *pFile = NULL;

etc

I've done a rebuild, and I've tried it on two different computers (one with win98, one with win2k), but the problem remains.

[Structural Integrity]

oh..... great....

I have managed to narrow the problem down to one line:
unsigned char terra[TERRAINSIZE*TERRAINSIZE];

It appears that I cannot declare a char aray of one MB (1024 * 1024)........ heh......
1024 * 1012 doesn't give a problem but anything higher gives an error.
Is there something I'm missing? Is there a limit of how much memory you can declare?!

[Gayle29uk]

Try using 'new' to allocate the memory rather than the way you're doing it. That way you won't be using the stack (which in VC++ is 1MB).

Guess how I know this? lol

[Pitchfork]

Originally posted by Structural Integrity
What is the problem here? It's a simple function of a simple object. If I call another function of the same object it works fine, but that function messes up:

terrain.loadTerrain("terrain.raw");

bool CTerrain::loadTerrain(char* filename)
{          //it doesn't even come here
	unsigned char terra[TERRAINSIZE*TERRAINSIZE];
	FILE *pFile = NULL;

etc

I've done a rebuild, and I've tried it on two different computers (one with win98, one with win2k), but the problem remains.

terrain.loadTerrain("terrain.raw");

bool CTerrain::loadTerrain(char* filename)
{          //it doesn't even come here
	unsigned char *terra[TERRAINSIZE*TERRAINSIZE] = new char[TERRAINSIZE*TERRAINSIZE];
	FILE *pFile = NULL;

etc

delete[] terra;

That is what Gayle mentioned, in fact you can assign more stack for your application (look at the compiler or editbin options in the manual, its /F for cl.exe and /STACK for editbin, I think), but I'd prefer the pointer way.

[Structural Integrity]

That array goes on the stack?!
WTF?
I always thought the array memory was allocated, not put on a stack.

I got around it by making the array part of my class, thus allocating the memory compile-time.
This still strikes me as "odd" though.

[Pitchfork]

No, it is a local variable and that's why in the stack frame. If you want to have it on heap you have to allocate it with new or malloc.

[JetLinus]

lol that's why i prefer VBasic ^^
*ducksandrunsaway*

[Cyp]

Could also declare it as
static unsigned char terra[TERRAINSIZE*TERRAINSIZE];

Should save (don't know how much) time allocating memory... Might also save time when accessing the array, since the address doesn't move, but might not either. Probably depends on the sanity of the writers of the compiler's optimizer. Although it's probably not an important amount of time to a function called loadTerrain.

(Same as declaring it outside a function, except it's supposed to get reset to zero before the program starts. It shouldn't make the program a megabyte bigger, but it's written by Micro$oft, so can't be sure.)


But new and delete are probably fine. (Haven't actually used new and delete, I just use malloc and free, though. Don't know if there is a difference.)

[Nodrog]

Originally posted by Cyp
But new and delete are probably fine. (Haven't actually used new and delete, I just use malloc and free, though. Don't know if there is a difference.)

As far as I know, the only difference is that new calls the constructor when allocating memory for classes. I cant imagine thered be any speed difference, but I could be wrong.

[Gayle29uk]

Originally posted by Nodrog
As far as I know, the only difference is that new calls the constructor when allocating memory for classes. I cant imagine thered be any speed difference, but I could be wrong.

We had a thread about this a few months ago. I think we came to the assumption that new/delete carried a slight overhead but I cba to check again.

[queball]

I don't remember that

[Structural Integrity]

Was that that "dynamic 2D array" thread? I think it was.
Anyway, I WOULD use new in this case. It isn't a performance critical part. For performance critical parts I'd use a global/static array anyway. I now used an array declared in the class itself. Perhaps I find another use for it in a later stage, if not, I'll change it to a dynamically allocated array.

[Gayle29uk]

Originally posted by Structural Integrity
Was that that "dynamic 2D array" thread? I think it was.

That's the one

On an only vaguely related note, not using the stack (as a habit) also makes you much less likely to introduce a script kiddie exploitable bug