Jump to content
  • Advertisement
Sign in to follow this  
SymLinked

Any reason not to change the stack size?

This topic is 3987 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 =]

Share this post


Link to post
Share on other sites
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!)

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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].

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!