why is the following an error.
it works perfectly for smaller sizes, but not for larger sizes.Code:unsigned long ulLRU[2048][2048]; for(x=0;x<2048;x++) for(y=0;y<2048;y++) ulLRU[x][y]=0;
is there another way to initialize these location to 0?
why is the following an error.
it works perfectly for smaller sizes, but not for larger sizes.Code:unsigned long ulLRU[2048][2048]; for(x=0;x<2048;x++) for(y=0;y<2048;y++) ulLRU[x][y]=0;
is there another way to initialize these location to 0?
"Hence to fight and conquer in all your battles is not supreme excellence;
supreme excellence consists in breaking the enemy's resistance without fighting."
Art of War Sun Tzu
It works perfectly fine on my compiler, unless of course, you somehow forgot to declare x and y.
As for shorter initialization:
Code:unsigned long ulLRU[2048][2048] = {0};
Scope is likely the key. Is the on the stack? That is a variable local to a function?
And is it a run-time error or compile-time error?
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
It is probably just too big for the stack. For larger arrays you need dynamic memory, which usually means use the standard C++ library's vector class.
Huh? Isn't the size of the stack and the heap managed by the OS inside a virtual memory area? If something's too big for the stack, wouldn't it mean it's also too big for the heap as well? Or do OS's generally penalize the size of the stack in favor of dynamic memory?
>Huh? Isn't the size of the stack and the heap managed by the OS inside a virtual memory area?
Implementations vary.
>If something's too big for the stack, wouldn't it mean it's also too big for the heap as well?
No.
>Or do OS's generally penalize the size of the stack in favor of dynamic memory?
Compile time vs runtime.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
The amount of memory available from the heap is much much greater than memory available for the stack. The stack size is set at compile time, but the heap depends on how much memory your machine has.
Yes, and in the OP's code, isn't he asking the OS to give him enough stack for a 2048x2048 integer array (exactly 4MBs which really isn't a lot by today's standards)?The stack size is set at compile time
So (with differences in OS implementation notwithstanding) can I assume that, in general, an OS will only allocate (say) 10% of it's memory for use as the stack by applications, and if you have gazillion applications running then try to squeeze an extra one in, the OS might throw a segmentation fault if that last straw broke its back?Code:unsigned long ulLRU[2048][2048];
Or do OSs in general have an injunction against applications which try to appropriate stack memory beyond a certain limit? "I'm an OS and I'll only give each application 2 MBs of stack memory. Anything which wants more can suck my gonads."
The stack is not a run-time allocation. It is likely a set size at compile time. Then at runtime the available pool needs to be big enough for the application's stack assumptions. Or something to that affect.Originally Posted by cunnus88
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
Setting the stack size (1)
http://msdn2.microsoft.com/en-us/lib...a6(VS.80).aspx
Setting the stack size (2)
Code:$ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited open files (-n) 256 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 2033 cpu time (seconds, -t) unlimited max user processes (-u) 63 virtual memory (kbytes, -v) 2097152
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
That's certainly an eye-opener. I guess I'd better be more frugal about stack variable definitions.stack size (kbytes, -s) 2033
