Quote:Original post by Goishin
Assuming that's correct

Technically, 'new' and 'new[]' allocate from the freestore, which is part of why you can't mix and match new/delete calls with malloc/free calls. (Note that you also cannot mix new/delete calls with new[]/delete[] calls.)

Quote:aren't there limits to using stack memory?

Yes.

Quote:And if there are, how do I find out what the sizes are (I'm assuming that this is operating system dependent)?

They're platform-dependent, and you usually find out (if you do) by running out.

Quote:Let's say I have some big huge array that I suddenly decide absolutely has to be on the stack

No such thing; trust me.

Quote:is there some way of dynamically resizing a stack to make room for it?

Not dynamically, no.

Quote:For that matter, are there pros/cons (other than memory size limitations) I would want memory from one or the other?

Not that are likely to matter for most programmers, no. Generally, KISS; the decision about where things go in memory depends on the quality of the needed memory (i.e. is there a specific, logical size it should be, as opposed to "this should be enough"?) rather than the quantity. When you *do* allocate from the freestore, use smart containers like std::vector that let you deal with memory *as if* it were on the stack, and be happy.

Quote:Original post by empirical2
Is this how it actually works though? I had a game that suddenly became very very slow to start up. I found this was because a function called many times at start up had a largish array in it. I guessed the speed was due to the memory was being re-allocated.

I moved the array to the global scope. Result game started at normal (near instant) speed. So what happened there?

Look at the generated assembly. In debug mode, the compiler will fill all local variables with junk (0xcccccccc in MSVC), and that'll get done every call of the function.
And if your array was of a non POD type, it'll be calling the constructor and destructor for each element of the array too.

Quote:Original post by rip-off
As for stack resizing, doesn't Linux automatically grow the stack for you?

Seems to, using the WOAH_THISISBIGSTRUCT example I got up to 39 before it segfaulted...

That would be around 1950K of memory used. I'd assume that it's defaulting to a 2MB stack.

Another thing to remember is that the run time library requires some stack space as well, and there's some function on the stack under main(), where the OS actually enters the program.

Quote:Original post by Evil Steve
Look at the generated assembly. In debug mode, the compiler will fill all local variables with junk (0xcccccccc in MSVC), and that'll get done every call of the function.

Ahhh! Good point. That must have why.