views:

637

answers:

3

I'm using Microsoft Visual C++ 2008 Express, and have a pretty annoying problem. It doesn't seem to happen in XP but in Vista I can't find a way around it. Whenever I declare variables non-dynamically, if their combined size exceeds about 30mb, the program will crash immediately at start-up. I know that Vista limits non-Win32 apps to 32mb of memory, but I don't think that's my issue. I'm using the Microsoft compiler, and it happens regardless if it's a win32 console app or a win32 window app. I just declare like...

int foo[1000][1000]

...or any combination of variables resulting in a similar size anywhere, and that's good-bye-application. Funny thing is, about 25 % of the times it runs even though this error exists. Am I missing some fundamental programming thingy here? Is static allocation obsolete? Am I going to have to redo the entire application to make use of dynamic allocation?

+1  A: 

There might be a stack size setting you need to set that is defaulting to something small. It has been a long time since I needed to play with those settings.

In the link options most likely

I only have MSDEV 2005 at work, but here is what it says about the stack linker option:

The /STACK option sets the size of the stack in bytes. This option is only for use when building an .exe file.

This option specifies the total stack allocation in virtual memory. The default stack size is 1 MB. The linker rounds up the specified value to the nearest 4 bytes.

EDIT

Unless you are doing your own memory management I can't see why you would allocate this statically. But even in that case I would dynamically allocate memory up front...

Tim
A: 

The problem is that non-dynamically allocated variables in methods are allocated on the stack, and the maximum stack size is MUCH less than the total available memory. I think it's around 30MB in Windows, yes. What you have done here is, ironically, this very site's namesake. A Stack Overflow.

Edit: According to http://www.cs.nyu.edu/exact/core/doc/stackOverflow.txt ,Window's maximum stack size is 32MB.

Joshua Carmody
*Static* variables are not allocated on the stack, whether they're local to functions/methods or not.
Will Dean
I don't think he meant static as in the keyword - rather not dynamically allocated... I will +1 because I don't think that deserves a minus...
Tim
Joshua - probably edit your post to reflect this. - or I will
Tim
Thanks Tim. You're correct, I used the wrong term. Actual static variables are something else altogether.
Joshua Carmody
+3  A: 

Is static allocation obsolete?

You're not doing static allocation - you're doing automatic allocation and as the others have said, you're running out of stack.

There are basically three common ways to reserve space for data in C++:

  1. On the stack - these are called 'automatic variables', and they're what ordinary function-local variables are. Assuming your "int foo[][]" is local to main(), then this is what this is. Automatic data is limited by the available stack size, but it's very fast to allocate (basically zero time).

  2. Statically - these are either function-local or class variables which are proceeded by the word 'static', or they're variables defined outside functions or classes scope. Static data is reserved by the compiler There's no allocation time overhead, but the memory is reserved for the entire run-time of the application.

  3. On the heap - these are allocated with 'new' or 'malloc' or some mechanism which makes those calls internally. Allocation and release are slow compared with the first two, but you can have as much memory as the system will give you, and you can return it when you've finished with it.

There are subtle variations on these three - for example alloca is a hybrid of 1 & 3, but these are the basics.

Will Dean