Any reason not to change the stack size?

Started by
23 comments, last by Jerax 16 years, 8 months ago
In Visual C++ you can change the stack reserve. Is there a reason I shouldn't do that? I know there is, hence my question. If there was no reason, then I guess people wouldn't use the heap except for when they don't know the size of the allocation. But that can't be the only reason, right?
Advertisement
generally if you're needing to do it then you are "wrongly" allocating big arrays or big objects on the stack when they should be allocated on the heap.

-me
Stack allocations have additional constraints besides merely size considerations.

First, there's the order: if A is allocated after B, then B will be deallocated after A.

Also, if A is allocated inside a function, then it will be deallocated when the execution leaves the function.

Then, as you said, the size of stack-allocated memory must be known at compile-time—only C99 allows variable-size stack arrays.
Quote:Original post by ToohrVyk
Then, as you said, the size of stack-allocated memory must be known at compile-time—only C99 allows variable-size stack arrays.


I have a multidimensional array[256][256] and it's too large to fit on the stack. The size of the array will not change, and I couldn't grasp how to allocate it on the heap. Edit: I saw a few solutions, but they were all too complicated for me to understand.

Do you think I still should avoid creating it on the stack? I'd have to increase the stack size for that. Feels bad.
int *myArray = new int[256*256]int get(int x, int y){    assert( y*256 + x < 256*256 );    return myArray[ y*256 + x ];}


and when you're done using it:

delete[] myArray;


-me
Quote:Original post by SymLinked
Quote:Original post by ToohrVyk
Then, as you said, the size of stack-allocated memory must be known at compile-time—only C99 allows variable-size stack arrays.


I have a multidimensional array[256][256] and it's too large to fit on the stack. The size of the array will not change, and I couldn't grasp how to allocate it on the heap. Edit: I saw a few solutions, but they were all too complicated for me to understand.

Do you think I still should avoid creating it on the stack? I'd have to increase the stack size for that. Feels bad.


Doing things the wrong way because you didn't understand the correct way is generally not a good idea. If you're having trouble understanding how to allocate multidimensional arrays you can use a single dimensional array and do some index arithmetic.

obj* array = new obj[256 * 256];
obj[row * 256 + col] instead of obj[row][col]
row∈[0,255], col∈[0,255]

EDIT: bah, too slow =]
Best regards, Omid
Quote:Original post by Palidine
*** Source Snippet Removed ***

and when you're done using it:

*** Source Snippet Removed ***

-me


Thanks Palidine. That's the approach I tried to understand previously. What worries me is how you access the array.
get (256, 256); // Wouldn't that overflow?

((256 * 256) + 256) = 65792
That would be more than the size of 65536.

I realize I'm missing something as many obviously use this method and it's recommended in different FAQ's, but what exactly is it I'm missing? Is my math incorrect up there? :)

Thanks again. (Edit: And thanks Omid!)
Quote:Original post by SymLinked
get (256, 256); // Wouldn't that overflow?

No, it would fail to compile (the assert would evaluate to false; assuming an assert does what I think it does).
Quote:Original post by SymLinked
Quote:Original post by Palidine
*** Source Snippet Removed ***

and when you're done using it:

*** Source Snippet Removed ***

-me


Thanks Palidine. That's the approach I tried to understand previously. What worries me is how you access the array.

get (256, 256); // Wouldn't that overflow?


((256 * 256) + 256) = 65792
That would be more than the size of 65536.

I realize I'm missing something as many obviously use this method and it's recommended in different FAQ's, but what exactly is it I'm missing? Is my math incorrect up there? :)

Thanks again.


Arrays are zero-based in C++, which means that if you allocate n elements you have indices i∈[0,(n-1)], so for n=256 the last index would be 255 and 256 would be out of bounds. That's why Palidine put an assert in the function for run-time bounds checking. The last element is
get(255, 255) which results in index 255*256 + 255 = 65535 = n-1

EDIT: run-time ofcourse, thank you Driv3MeFar [smile]

[Edited by - Omid Ghavami on August 14, 2007 4:55:41 PM]
Best regards, Omid
Quote:Original post by SymLinked
Quote:Original post by Palidine
*** Source Snippet Removed ***

and when you're done using it:

*** Source Snippet Removed ***

-me


Thanks Palidine. That's the approach I tried to understand previously. What worries me is how you access the array.
get (256, 256); // Wouldn't that overflow?

((256 * 256) + 256) = 65792
That would be more than the size of 65536.

I realize I'm missing something as many obviously use this method and it's recommended in different FAQ's, but what exactly is it I'm missing? Is my math incorrect up there? :)

Thanks again. (Edit: And thanks Omid!)


0 based index, so 256 is not a valid index [smile].

This topic is closed to new replies.

Advertisement