blocks|key|2582760|text|我从来不担心这个。如果有堆栈溢出，我很快就会知道。此外，在C%2B%2B中，实际上很难在堆栈上创建非常大的对象。这样做的唯一方法是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2582761|struct+S+{
+++char+big[1000000];
};|code-block|syntax|javascript|2582762|但是使用std::string或std::vector可以解决这个问题。|2582763|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I never worry about it. If there is a stack overflow, I will soon know about it. Also, in C++ it is actually very hard to create very large objects on the stack. About the only way of doing it is:

<pre><code>struct S {
 char big[1000000];
};
</code></pre>

but use of std::string or std::vector makes that problem go away.

blocks|key|3935628|text|你不应该从一开始就避免使用堆栈来分配大对象吗？使用堆，不是吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3935629|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Shouldn't you be avoiding using the stack for allocating large objects in the first place? Use the heap, no?

blocks|key|2582781|text|你开始担心堆栈的大小，因为|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2582782|2582783|您的团队中有人巧妙地发明了一个不断运行的递归函数...|unordered-list-item|2582784|您创建了一个线程工厂，突然需要原来需要的堆栈的十倍(每个线程都需要一个堆栈=>您拥有的线程越多，给定堆栈大小剩下的可用空间就越少)|2582785|2582786|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|L|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|M|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|N|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|J|$]]

You start to worry about stack size when

<ul>
<li>someone on your team cunningly invents a recursive function that goes on and on and on...</li>
<li>you create a thread factory and suddenly need a tenfold of the stack that you used to need (each thread needs a stack => the more threads you have, the less free space remains for a given stack size)</li>
</ul>

blocks|key|670390|text|我的经验:当你使用递归函数时，要注意堆栈的大小！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|670391|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

my experience: 
when you use recursive functions, take care of the stack size!!

blocks|key|155693|text|在微控制器上，您通常需要显式地指定堆栈空间(或者，在RAM用于静态分配%2B任何RAM程序空间后，您会得到剩余的空间)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|155694|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You care about it on a microcontroller, where you often have to specify stack space explicitly (or you get whatever's left over after RAM gets used for static allocation + any RAM program space).

blocks|key|3935751|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3935752|当您在一种允许您对非常大的对象使用自动分配的语言中进行编程时...|blockquote|3935753|3935754|3935755|如果我想分配一个非常大的对象，而不是在堆栈上，我可能会在堆上分配它，但包装在auto_ptr中(在这种情况下，当它超出作用域时，它将被释放，就像堆栈驻留对象一样，但不用担心堆栈大小)。|offset|length|style|CODE|3935756|3935757|+...您何时以及如何担心堆栈大小？|3935758|3935759|3935760|出于习惯，我保守地使用堆栈(例如，任何大于512字节的对象都被分配到堆上)，并且我知道堆栈有多大(例如，默认情况下大约1兆字节)，因此我知道我不需要担心它。|3935761|3935762|关于堆栈大小的推理有什么经验法则吗？|3935763|3935764|3935765|3935766|非常大的对象可能会破坏堆栈|unordered-list-item|3935767|非常深的递归可能会破坏堆栈|3935768|如果有许多线程，并且如果您在内存有限的嵌入式设备上运行，则默认的堆栈大小可能太大(占用太多内存)，在这种情况下，您可能需要使用O/S或链接器选项来减小每个线程的堆栈大小。|3935769|3935770|entityMap^0|0|0|0|0|12|8|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|18|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|19|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1A|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|1B|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|1C|7|@$H|1D|I|1E|J|K]]|8|@]|9|$]]|$1|L|3|-4|4|5|6|1F|7|@]|8|@]|9|$]]|$1|M|3|N|4|C|6|1G|7|@]|8|@]|9|$]]|$1|O|3|-4|4|5|6|1H|7|@]|8|@]|9|$]]|$1|P|3|-4|4|5|6|1I|7|@]|8|@]|9|$]]|$1|Q|3|R|4|5|6|1J|7|@]|8|@]|9|$]]|$1|S|3|-4|4|5|6|1K|7|@]|8|@]|9|$]]|$1|T|3|U|4|C|6|1L|7|@]|8|@]|9|$]]|$1|V|3|-4|4|5|6|1M|7|@]|8|@]|9|$]]|$1|W|3|-4|4|5|6|1N|7|@]|8|@]|9|$]]|$1|X|3|-4|4|5|6|1O|7|@]|8|@]|9|$]]|$1|Y|3|Z|4|10|6|1P|7|@]|8|@]|9|$]]|$1|11|3|12|4|10|6|1Q|7|@]|8|@]|9|$]]|$1|13|3|14|4|10|6|1R|7|@]|8|@]|9|$]]|$1|15|3|-4|4|5|6|1S|7|@]|8|@]|9|$]]|$1|16|3|-4|4|5|6|1T|7|@]|8|@]|9|$]]]|17|$]]

<blockquote>
 When you are programming in a language that allows you to use automatic allocation for very large objects ...
</blockquote>

If I want to allocate a very large object, then instead of on the stack I might allocate it on the heap but wrapped in an <code>auto_ptr</code> (in which case it will be deallocated when it goes out of scope, just like a stack-resident object, but without worrying about stack size).

<blockquote>
 ... when and how do you worry about stack size?
</blockquote>

I use the stack conservatively out of habit (e.g. any object bigger than about 512 bytes is allocated on the heap instead), and I know how big the stack is (e.g. about a megabyte by default), and therefore know that I don't need to worry about it.

<blockquote>
 Are there any rules of thumb for reasoning about stack size?
</blockquote>

<ul>
<li>Very big objects can blow the stack</li>
<li>Very deep recursion can blow the stack</li>
<li>The default stack size might be too big (take too much total memory) if there are many threads and if you're running on a limited-memory embedded device, in which case you might want to use an O/S API or linker option to reduce the size of the stack per thread.</li>
</ul>

blocks|key|155762|text|唯一的时间是当你进行线程处理并且必须自己定义它的时候，当你在做递归的时候，或者当你出于某种原因分配到堆栈的时候。否则，编译器会确保您有足够的堆栈空间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|155763|默认情况下，CreateThread仅为堆栈分配0x100000字节。|155764|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Only time really is when you are threading and have to define it yourself, when you are doing recursion or when for some reason you are allocating to the stack. Otherwise the compiler takes care of making sure you have enough stack space.

CreateThread by default only allocates 0x100000 bytes for the stack.

blocks|key|678782|text|一般来说，堆栈上的大分配是不好的，原因有几个，其中最重要的原因是它们可能导致问题很长时间内隐藏得很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|678783|问题是，检测堆栈溢出并不容易，而且大的分配可能会破坏大多数常用的方法。|678784|如果处理器没有内存管理或内存保护单元，则必须格外小心。但是如果使用某种类型的MMU或MPU，硬件可能无法检测到堆栈溢出。一种常见的方案是在堆栈下面保留一个页面以捕获溢出，如果大的堆栈对象大于一个页面，则会失败。可能会有另一个线程的堆栈在那里，哦！你刚刚创造了一个非常讨厌的，很难找到的bug。|678785|无限递归通常很容易捕获，因为堆栈增长通常很小，并且会触发硬件保护。|678786|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

In general, big allocations on the stack are bad for several reasons, not the least of which is that they can cause problems to remain well hidden for a long time.

The problem is that detecting stack overflow is not easy, and big allocations can subvert most of the commonly used methods.

If the processor has no memory management or memory protection unit, you have to be particularly careful. But event with some sort of MMU or MPU, the hardware can fail to detect a stack overflow. One common scheme, reserving a page below the stack to catch overflow, fails if the big stack object is bigger than a page. There just might be the stack of another thread sitting there and oops! you just created a very nasty, hard to find bug.

Unlimited recursion is usually easy to catch because the stack growth is usually small and will trigger the hardware protection.

blocks|key|155821|text|在决定是否在堆栈还是堆上分配对象时，还需要考虑一些性能问题。在堆栈上分配内存非常快-它只需要移动堆栈指针，而使用new/delete或malloc/free的动态分配/释放是相当昂贵的，特别是在每个线程没有堆的多线程代码中。如果您有一个在紧密循环中调用的函数，那么您很可能会在将较大的对象放入堆栈方面犯错误，并牢记其他答案中提到的所有多线程注意事项，即使这意味着必须增加堆栈空间，而大多数链接器都允许这样做。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|155822|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

When deciding whether to allocate objects on the stack vs. the heap, there are also perf issues to be taken into consideration. Allocation of memory on the stack is very fast - it just involves moving the stack pointer, whereas dynamic allocation/deallocation using new/delete or malloc/free is fairly expensive, especially in multithreaded code that doesn't have a heap per thread. If you have a function that is being called in a tight loop, you might well err on the side of putting larger objects on the stack, keeping all of the multithreading caveats mentioned in other answers in mind, even if that means having to increase stack space, which most linkers will allow you to do.

blocks|key|670486|text|当调用堆栈非常深，并且每个函数(在堆栈上)分配变量时，我担心嵌入式系统上的堆栈大小。通常，当系统由于堆栈上的变量更改(堆栈溢出)而意外崩溃时，就会发生死机。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|670487|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I worry about stack size on embedded systems when call stack goes very deep and each function allocates variables (on the stack). Generally, panic evolves when the system crashes unexpectedly due to variables changing on the stack (the stack overflows).

blocks|key|678838|text|如果你在为一个很小的嵌入式平台写代码，你会一直担心它，但你也知道它到底有多大，并且可能有一些有用的工具来寻找堆栈的最高标记。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|678839|如果你没有这样做，那么在你的程序崩溃之前不要担心:)除非你正在分配非常大的对象(几十KB)，否则这永远不会是一个问题。|678840|但是，请注意，根据定义，堆栈上的对象是临时的。频繁地构造(可能是析构)大型对象可能会导致性能问题-因此，如果您有一个大型对象，出于堆栈大小以外的其他原因，它可能应该是持久的和基于堆的。|678841|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If you're writing for a tiny little embedded platform, you worry about it all the time, but you also know exactly how big it is, and probably have some useful tools available to find the high-water mark of the stack.

If you aren't, then don't worry until your program crashes :)
Unless you are allocating seriously huge objects (many tens of KB), then it is never going to be a problem.

Note, however, that objects on the stack are, by definition, temporary. Constructing (and possibly destructing) large objects frequently may cause you a performance problem - so if you have a large object it probably should be persistent and heap-based for reasons other than stack size.

blocks|key|155938|text|在Symbian上玩了很多这个游戏:什么时候使用TBuf+(堆栈上有存储的字符串)，什么时候使用HBufC+(它在堆上分配字符串存储，就像std::+string，所以你必须处理Leave，你的函数需要失败的方法)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|155939|当时(也许现在我还不确定)，Symbian线程默认有4k的堆栈。要操作文件名，您需要使用多达512个字节(256个字符)。|155940|正如您可以想象的那样，公认的智慧是“永远不要将文件名放在堆栈上”。但实际上，事实证明，你可以比你想象的更多地逃脱惩罚。当我们开始运行真实程序(TM)时，比如游戏，我们发现我们需要比默认堆栈大小更多的东西，这不是由于文件名或其他特定的大对象，而是由于游戏代码的复杂性。|155941|如果使用堆栈可以使您的代码更简单，并且只要您进行了正确的测试，并且不会完全过火(不要有多个级别的文件处理函数都将一个文件名放在堆栈上)，那么我会说，试一试。尤其是当函数需要能够失败的时候，不管你使用的是栈还是堆。如果出现错误，您要么将堆栈大小加倍并在以后更加小心，要么在函数中添加另一个失败案例。世界末日也不是。|155942|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Played this game a lot on Symbian: when to use TBuf (a string with storage on the stack), and when to use HBufC (which allocate the string storage on the heap, like std::string, so you have to cope with Leave, and your function needs a means of failing).

At the time (maybe still, I'm not sure), Symbian threads had 4k of stack by default. To manipulate filenames, you need to count on using up to 512 bytes (256 characters).

As you can imagine, the received wisdom was "never put a filename on the stack". But actually, it turned out that you could get away with it a lot more often than you'd think. When we started running real programs (TM), such as games, we found that we needed way more than the default stack size anyway, and it wasn't due to filenames or other specific large objects, it was due to the complexity of the game code.

If using stack makes your code simpler, and as long as you're testing properly, and as long as you don't go completely overboard (don't have multiple levels of file-handling functions which all put a filename on the stack), then I'd say just try it. Especially if the function would need to be able to fail anyway, whether you're using stack or heap. If it goes wrong, you either double the stack size and be more careful in future, or you add another failure case to your function. Neither is the end of the world.

blocks|key|2582921|text|通常情况下，堆栈上不能真正拥有大对象。它们几乎总是在内部使用堆，所以即使它们“在堆栈上”，它们的数据成员也不是。即使是一个有大量数据成员的对象，在堆栈上的长度通常也在64字节以下，其余的在堆上。堆栈通常只有在你有很多线程和大量递归的时候才会成为问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2582922|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You usually can't really have large objects on the stack. They almost always use the heap internally so even if they are 'on the stack' their data members are not. Even an object with tons of data members will usually be under 64 bytes on the stack, the rest on the heap. The stack usually only becomes an issue these days when you have lots of threads and lots of recursion.

blocks|key|155996|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|155997|你什么时候会担心栈的大小？|blockquote|155998|155999|156000|绝不可能。|156001|如果你有堆栈大小问题，这意味着你做了其他错误的事情，应该修复它，而不是担心堆栈大小。|156002|对于实例：|156003|156004|在堆栈上分配不合理的大结构-不要这样做。在堆上分配。|unordered-list-item|156005|具有长得离谱的递归。我的意思是按照绘制图像和使用递归在像素上迭代的顺序。-找到更好的方法来做这件事。|156006|156007|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|U|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|V|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|W|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|X|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|Y|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|Z|7|@]|8|@]|9|$]]|$1|J|3|K|4|5|6|10|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|11|7|@]|8|@]|9|$]]|$1|M|3|N|4|O|6|12|7|@]|8|@]|9|$]]|$1|P|3|Q|4|O|6|13|7|@]|8|@]|9|$]]|$1|R|3|-4|4|5|6|14|7|@]|8|@]|9|$]]|$1|S|3|-4|4|5|6|15|7|@]|8|@]|9|$]]]|T|$]]

<blockquote>
 When do you worry about stack size?
</blockquote>

Never. 

If you have stack size problems it means you're doing something else wrong and should fix that instead of worrying about stack size. 
For instace:

<ul>
<li>Allocating unreasonably large structures on the stack - don't do it. allocate on the heap.</li>
<li>Having a ridiculously long recursion. I mean in the order of painting an image and iterating over the pixels using recursion. - find a better way to do it.</li>
</ul>

blocks|key|156018|text|我不这样认为，在编写正常的程序时担心这些事情要么是过早的悲观，要么是过早的优化。无论如何，在现代计算机上很难把事情搞得一团糟。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|156019|我曾经写过一个CSV解析器，在尝试获得最佳性能的同时，我在堆栈上分配了数千个1K缓冲区。性能非常出色，但RAM从正常的30MB内存增加到了大约1+1GB。这是因为CSV文件中的每个单元都有固定大小的1K缓冲区。|156020|就像每个人都说的，除非你在做递归，否则你不必担心它。|156021|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I don't. Worrying about this things whilst writing programming normal things is either a case of premature pessimization or premature optimization. It's pretty hard to blow things up on a modern computer anyway.

I once wrote a CSV parser and whilst playing around with trying to get the best performance I was allocating hundereds of thousands of 1K buffers on the stack. The performance was stellar but the RAM went up to about 1GB from memory from normal 30MB. This was due to each cell in the CSV file had a fixed size 1K buffer.

Like everyone is saying unless you are doing recursion you do not have to worry about it.

blocks|key|2582961|text|当您编写一个回调，该回调将从您无法控制的运行时(例如，MS+RPC运行时)产生的线程中调用时，您会担心这个问题，堆栈大小由该运行时自行决定。不知何故，like+this。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2582962|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1345478/how-to-detect-the-amount-of-stack-space-available-to-my-program^0|23|9|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You worry about it when you write a callback that will be called from threads spawned by a runtime you don't control (for example, MS RPC runtime) with stack size at the discretion of that runtime. Somehow <a href="https://stackoverflow.com/questions/1345478/how-to-detect-the-amount-of-stack-space-available-to-my-program">like this</a>.

blocks|key|156046|text|在以下情况下，我遇到过堆栈空间不足问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|156047|156048|A函数意外地将自己称为|unordered-list-item|156049|A函数使用递归到深层代码|156050|A函数在堆栈上分配一个大对象，并且有一个堆。|156051|A函数使用复杂的模板，编译器崩溃<|156052|>F29>|156053|假设我：|156054|156055|在堆上分配大对象(例如，使用"auto_ptr+foo+=+new+Foo“而不是"Foo+foo”)|156056|使用递归judiciously.|156057|156058|我通常没有任何问题，所以不幸的是，我不知道什么是好的默认值。|156059|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|16|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|Q|3|R|5|E|7|18|8|@]|9|@]|A|$]]|$1|S|3|T|5|E|7|19|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1B|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|Y|$]]

I have had problems running out of stack space when:

<ul>
<li>A function accidentally calls itself</li>
<li>A function uses recursion to a deep level</li>
<li>A function allocates a large object on the stack, and there is a heap.</li>
<li>A function uses complicated templates and the compiler crashes</li>
</ul>

Provided I:

<ul>
<li>Allocate large objects on the heap (eg. using "auto_ptr foo = new Foo" instead of "Foo foo")</li>
<li>Use recursion judiciously.</li>
</ul>

I don't normally have any problems, so unfortunately don't know what good defaults should be.

blocks|key|3936133|text|在以下情况下，您开始担心堆栈大小：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3936134|3936135|当你的程序崩溃时-通常你第一次看到这些bug时会觉得很奇怪：)|unordered-list-item|3936136|你正在运行一个使用递归的算法，而将用户输入作为它的一个参数(你不知道你的算法可以使用多少堆栈)|offset|length|style|BOLD|3936137|你正在嵌入式平台(或每个资源都很重要的平台)上运行。通常在这些平台上，堆栈是在进程创建之前分配的-所以必须对堆栈需求做出一个很好的估计，当在线程/进程/任务中执行的代码非常大，并且有很多函数调用深入堆栈并生成巨大的调用堆栈时，您在堆栈上创建对象依赖于一些可由用户输入修改的参数(参见以下示例)|3936138|。这通常发生在结合了许多触发器和事件处理的大型框架中(例如:接收_单击->查找_单击_窗口->发送消息_到_窗口->进程消息->过程_单击->+is_inside_region->+trigger_drawing->+write_to_file->+...+)。简而言之，在复杂代码或未知/二进制第三方模块的情况下，您应该担心调用堆栈。|3936139|3936140|可修改的输入参数示例：|3936141|in+my_func(size_t+input_param)
{
++char+buffer[input_param];
++//+or+any+other+initialization+of+a+big+object+on+the+stack
++....
}|code-block|syntax|javascript|3936142|一条建议：|3936143|3936144|您应该用一些幻数标记堆栈(以防您分配它)，并检查这些幻数是否会被修改(在这种情况下，堆栈对于任务/线程/进程来说是不够的，可能应该增加)|3936145|3936146|entityMap^0|0|0|0|B|5|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|17|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|18|8|@$H|19|I|1A|J|K]]|9|@]|A|$]]|$1|L|3|M|5|E|7|1B|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|1C|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1E|8|@]|9|@]|A|$]]|$1|S|3|T|5|U|7|1F|8|@]|9|@]|A|$V|W]]|$1|X|3|Y|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|10|3|11|5|E|7|1I|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|14|$]]

You start to worry about stack size when:

<ul>
<li>when your program crashes - usually these bugs tend to be weird first time you see them :)</li>
<li>you are running an algorithm that uses recursion and has user input as one of its parameters (you don't know how much stack your algorithm could use)</li>
<li>you are running on embedded platforms (or platforms where each resource is important). Usually on these platforms stack is allocated before process is created - so a good estimation about stack requirements must be made</li>
<li>you are creating objects on the stack depending on some parameters modifiable by user input (see the sample below)</li>
<li>when the code executed in a thread/process/task is very big and there are a lot of function calls that go deep into the stack and generate a huge call-stack. This usually happens in big frameworks that combine a lot of triggers and event processing (a GUI framework; for example: receive_click-> find_clicked_window->
send_msg_to_window->
process_message->
process_click->
is_inside_region->
trigger_drawing->
write_to_file-> ... ). To put it short, you should worry about call-stack in case of complex code or unknown/binary 3rd party modules.</li>
</ul>

sample for modifiable input parameters:

<pre><code>in my_func(size_t input_param)
{
 char buffer[input_param];
 // or any other initialization of a big object on the stack
 ....
}
</code></pre>

An advice:

<ul>
<li>you should mark the stack with some magic numbers (in case you allocate it) and check if those magic numbers will be modified (in that case the stack will not be enough for the task/thread/process and should probably be increased)</li>
</ul>

blocks|key|3936172|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3936173|当你为PC编写的代码突然应该在手机上运行时|ordered-list-item|3936174|当你移植到手机上运行的代码突然应该在DSP|3936175|上运行时|3936176|(是的，这些都是现实生活中的混乱。)|3936177|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|M|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|N|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|O|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|P|7|@]|8|@]|9|$]]|$1|J|3|-4|4|5|6|Q|7|@]|8|@]|9|$]]]|K|$]]

<ol>
<li>When the code you've written for a PC suddenly is supposed to run on a mobile phone </li>
<li>When the code you've ported to run on a mobile phone suddenly is supposed to run on a DSP</li>
</ol>

(And yes, these are real-life snafus.)

When you are programming in a language that allows you to use automatic allocation for very large objects, when and how do you worry about stack size? Are there any rules of thumb for reasoning about stack size?

When do you worry about stack size?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

当您在一种允许对非常大的对象使用自动分配的语言中进行编程时，您何时以及如何担心堆栈大小？关于堆栈大小的推理有什么经验法则吗？

问什么时候你会担心栈的大小？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候你会担心栈的大小？EN