Back to General and Gameplay Programming

Any reason not to change the stack size?

SymLinked · 2007-08-16T07:09:05

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?

General and Gameplay Programming Programming

Started by SymLinked August 14, 2007 03:20 PM

23 comments, last by Jerax 16 years, 8 months ago

iMalc

2,466

August 15, 2007 03:54 AM

Quote:Original post by Richy2k
You can do a compile time assert if you so very wish:
#define COMPILE_TIME_ASSERT( a )     {        int Temp[ ( a ) ? 1 : 0 ];    }
Although these generally shouldn't be needed, used, or glanced at.

Compile-time asserts are an awesome tool!
I wouldn't do it like that though. In a debug build at least that will actually take up the size of an int. You needn't actually declare an array, simply doing a typedef of an invalid sized array will do. The second problem is that some compilers allow zero lengthed arrays, or at least only give a warning. Better to make the 0 a -1.

This bring you to up to par with the definition of C_ASSERT that already come with MSVC.

If you want to go furthur and get a nicer error message look into boost's STATIC_ASSERT instead.

"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

Antheus

2,410

August 15, 2007 10:20 AM

Quote:Original post by iMalc
I wouldn't do it like that though. In a debug build at least that will actually take up the size of an int. You needn't actually declare an array, simply doing a typedef of an invalid sized array will do. The second problem is that some compilers allow zero lengthed arrays, or at least only give a warning. Better to make the 0 a -1.

I prefer templates:

template <bool b> struct COMPILE_ASSERT_FAILURE; template <> struct COMPILE_ASSERT_FAILURE<true> { }; #define COMPILE_ASSERT(name, expr) struct name : public COMPILE_ASSERT_FAILURE<(bool)(expr)> { }

This also dumps the "name" during compile output with the message.

herc

132

August 15, 2007 04:30 PM

@all: thanks for your interesting insights why one shouldnt make the default stack size too big. very interesting indeed.

Vorpy

869

August 15, 2007 10:02 PM

There's no need to use the stack for speed. You can always allocate a large chunk of memory and use it as your own stack for your large arrays, managing the memory yourself. The initial allocation only needs to be done once and after that it can be used as efficiently as the program stack, since it is easy to manage memory that is always allocated and deallocated in last-in-first-out order. Then you just need to make sure the stack you make is big enough for your data...if your function doesn't need to be reentrant, you can make the array global or dynamically allocate enough space for it just once.

Jerax

126

August 16, 2007 07:09 AM

Quote:Original post by jflanglois
There's another way to go about it (which is interesting because it allows natural usage, while also having decent spatial locality):

*snip*

But then again, if you're going to go through the trouble, you might as well install and use boost::multi_array (or at least wrap Palidine's solution so that you have a subscript operator).

Or just use:

int (*a)[256] = new int[256][256];a[x][y] = 0;delete [] a;

Any reason not to change the stack size?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Any reason not to change the stack size?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines