terrain.loadTerrain("terrain.raw");
bool CTerrain::loadTerrain(char* filename)
{
unsigned char terra[TERRAINSIZE*TERRAINSIZE];
FILE *pFile = NULL;
etc
As soon as it calls this function it gives an error, it doesn''t even enter the function. When I call another function of the same object (a few thousand times each frame), it goes fine.
What am I missing? I must be something obvious.
Visual C++: stack overflow
I have no idea where this runtime error is coming from. I can''t see anything I''ve done wrong:
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...... nasty
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?!
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...... nasty
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?!
You are overflowing the stack. The stack is only of limited size, and a variable of that size is far beyond what the stack can handle.
Store the terrain buffer on the heap (using new/malloc).
Store the terrain buffer on the heap (using new/malloc).
using:
unsigned char whatever[1024*1024];
works just fine but you need to place it globally and not inside the function.
____________________________________________________________
Try RealityRift at www.planetrift.com
unsigned char whatever[1024*1024];
works just fine but you need to place it globally and not inside the function.
____________________________________________________________
Try RealityRift at www.planetrift.com
Look at the documentation for your compiler. You should be able to increase the size of the stack.
Thanks!
I got around it by making the array part of the class.
Still, I didn''t know this. I always assumed that any array, whereever I declared it, was put in memory, not on the stack.
Is this something particular to microsoft visual, or is this something that every compiler does?
A more technical question: WHY is it put on the stack? Why not in memory? Is this a speed issue?
TY
I got around it by making the array part of the class.
Still, I didn''t know this. I always assumed that any array, whereever I declared it, was put in memory, not on the stack.
Is this something particular to microsoft visual, or is this something that every compiler does?
A more technical question: WHY is it put on the stack? Why not in memory? Is this a speed issue?
TY
quote:Original post by Structural
Thanks!
I got around it by making the array part of the class.
Still, I didn''t know this. I always assumed that any array, whereever I declared it, was put in memory, not on the stack.
Is this something particular to microsoft visual, or is this something that every compiler does?
A more technical question: WHY is it put on the stack? Why not in memory? Is this a speed issue?
TY
The compiler optimizes the variables inside a function to be more efficient and that generally means stack and registers since they are most effective (performance) and as long as it is possible to do so. One could argue that there should be a "memory" just as there is a "register".
____________________________________________________________
Try RealityRift at www.planetrift.com
Your array sits on the stack,not the heap, its probably being destroyed while you''re trying to read it. That''s why you get your exeption.
Cheers
Chris
Cheers
Chris
Some languages that don''t support recursion have only 1 static copy of all local variables. That''s all that is needed in this case. A stack supports recursion efficiently, and saves a little space.
You do only have 1 copy of static locals, and C does support recursion. That''s why it''s dodgy to save stack space by changing locals to static locals, since if you call the function recursively you wont get a new copy. static locals also disallow re-entrancy for multithreaded functions unless you use a critical section or something similar.
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement