何时应该增加堆栈大小（Visual Studio C++）[关闭]

Question

. This question is opinion-based . It is not currently accepting answers.

---

Update the question so it can be answered with facts and citations by editing this post .

Closed 3 hours ago .

Improve this question

When should we increase the stack size for a C++ program?

Why isn't it unlimited and are there any reasons for not increasing the stack size?

And does a program crash if the stack is full?

And also can we increase the stack size for a particular thread?

Answer 1

When should we increase the stack size for a C++ program?

When you have a specific program or a use case that overflows the stack. Note that the ideal solution is to modify the program or algorithm to behave within reasonable stack size, but that isn't always possible in practice (eg you have a program you cannot modify).

Why isn't it unlimited and are there any reasons for not increasing the stack size?

Because is not possible within the current architecture. In the virtual memory space of a program there are multiple stacks, one for each thread so specific limited space must be reserved for each stack. Keep in mind that a stack cannot be fragmented and cannot move (relative to the virtual memory space).

And does a program crash if the stack is full?

Please forgive my pedantic note: If the stack is full but you don't exceed it there is not problem. The problem is when the program overflows the stack.

I am not sure exactly. I think there is OS level protection against stack overflow in which case the program crashes with stack overflow exception. If am wrong and there is no protection (or if there is a setting to disable it) it depends on what it is in the memory you overflow. In any case, nothing good happens.

Why is the stack size set so small by default?

ok, it's not your question, but I feel it ties in here neatly

It's not. The OSes need to find a balance between too big of a stack and too small. Too big and you cut into the heap memory, too small and you make programs overflow it.

What can reside on the stack: call frames and local variables allocated on the stack. Call frames are very small (they usually contain just 1 pointer per frame) and local variables usually are pretty small. Big objects go on the heap.

What can overflow a stack? The most likely culprit is recursion. A recursive algorithm can easily overflow the stack with a big maximum recursion depth. But every recursive algorithm can be rewritten. Either there is an equivalent iterative algorithm or simply use a stack on the heap instead. That is the reason why in stack based memory allocation languages like C and C++ in the real world recursive algorithms with unbound recursion depths are avoided.