内存分配：静态还是动态？ [英] Memory Allocation : Static or Dynamic?
问题描述
哪种分配（静态/动态）适用于当我的内存为
已满且没有空间时我们试图为超载内存分配的情况分配。
如果分配都不可能会发生什么。
Sworna vidhya
Which allocation (Static / Dynamic) is suitable for the situation when
we are trying to allocate for a overloaded memory when the memory is
full and no space to allocate.
What will happen if both the allocation is impossible.
Sworna vidhya
推荐答案
2008年5月8日16:58， sw * *******************@gmail.com 写道：
On 8 May 2008 at 16:58, sw********************@gmail.com wrote:
哪个分配（静态/动态）适用于当内存为
已满并且无需分配空间时我们试图为超载内存分配的情况。
如果分配都不可能，会发生什么。
Which allocation (Static / Dynamic) is suitable for the situation when
we are trying to allocate for a overloaded memory when the memory is
full and no space to allocate.
What will happen if both the allocation is impossible.
绝对使用动态分配如果存在运行内存的严重风险（并且作为一般原则，不要'''''' t在堆栈上分配大数组
）。如果malloc（）失败，你可以检测到它（它将返回一个
空指针）并尝试恢复或干净地退出。如果您的自动变量耗尽了
静态内存，那么最有可能的结果是，堆将在没有警告的情况下被破坏。如果你很幸运，
你的程序很快就会崩溃;如果你运气不好，你可以继续处理损坏的数据。
你的进程的虚拟地址是怎么回事空间，记忆
安排如下：
---------------------- -
| |
|堆叠|
| （向下长大）|
| |
-----------------------
| |
|免费记忆|
| （适用于|
|堆栈或堆）|
| |
-----------------------
| |
| HEAP |
| （向上成长）|
| |
-----------------------
所以如果你用完了释放内存并溢出堆栈，你可以看到
会发生坏事。
Definitely use dynamic allocation if there''s a serious risk of running
out of memory (and as a general principle, don''t allocate large arrays
on the stack). If malloc() fails, you can detect this (it will return a
null pointer) and attempt to recover or exit cleanly. If you run out of
static memory for your automatic variables, the most likely outcome is
that the heap will become corrupted without warning. If you''re lucky,
your program will quickly segfault; if your unlucky, you could go on for
hours processing corrupted data.
What''s going on is that in your process''s virtual address space, memory
is arranged like this:
-----------------------
| |
| STACK |
| (grows downwards) |
| |
-----------------------
| |
| FREE MEMORY |
| (available for the |
| stack or heap) |
| |
-----------------------
| |
| HEAP |
| (grows upwards) |
| |
-----------------------
So if you run out of free memory and overflow the stack, you can see
that bad things will happen.
文章< 4f ** ********************************@u6g2000prc.g ooglegroups.com> ;,
< ; sw ******************** @ gmail.comwrote：
In article <4f**********************************@u6g2000prc.g ooglegroups.com>,
<sw********************@gmail.comwrote:
>哪个分配（静态/动态）适用于当内存充满且没有分配空间时我们试图为超载内存分配的情况。
如果两个分配都不可能会发生什么。
>Which allocation (Static / Dynamic) is suitable for the situation when
we are trying to allocate for a overloaded memory when the memory is
full and no space to allocate.
What will happen if both the allocation is impossible.
对我来说听起来像是一个家庭作业问题...
但无论如何：动态分配的失败已明确定义
结果：所有动态分配函数都有方法
表示它们无法分配更多内存。这个
允许你在内存已满时干净地检测并采取行动。
静态内存没有明确指示
分配失败的方法，这样你就无法干净地检测并采取行动。
如果静态内存分配失败，那么* some *
系统会产生一个信号，可以通过信号处理机制来处理，但是C89至少没有为这个条件定义
a信号而且没有记录它可能是一个
的可能性，因此任何此类信号都将是OS扩展，而不是C本身b
本身的一部分。在C89中，如果系统本身引发了在C89中专门定义的任何信号，那么从信号处理程序返回后程序的行为是未定义的 - 所有/或
C89定义的信号适用于大多数操作系统通常为致命的条件。 （注意：如果程序本身
使用raise（）来引发C89定义的信号之一，那么从信号处理程序返回的
- 很好地定义了。）
我必须查看C99定义的信号的细节
以查看是否有任何信号返回信号
处理程序定义良好。 C99与C89略有不同，因为
有操作（例如有符号整数的溢出）C89
只是让行为完全未定义，但C99
表示行为未定义或者系统可以选择性地提出实现定义的信号。这就是语言
律师赚钱的地方，争论的是
行为之间的差异 - 总是未定义的，而行为是
实现可能定义为未定义！
-
所有人类知识都采用解释的形式。
- Walter本杰明
Sounds like a homework question to me...
But anyhow: The failure of dynamic allocation has well-defined
results: all of the dynamic allocation functions have methods
of indicating that they were unable to allocate more memory. This
allows you to cleanly detect and take action when memory is full.
Static memory has no defined method of indicating failure of
allocation, so you cannot cleanly detect and take action in
such cases.
If there is a failure of static memory allocation, then *some*
systems will generate a signal that can be handled through
the signal handling mechanism, but C89 at least does not define
a signal for this condition and does not document it as a
possibility, so any such signal would be an OS extension, not part of C
itself. And in C89, if the system itself raises any of the signals
defined specifically in C89, then behaviour of the program
after returning from the signal handler is undefined -- all of
the C89- defined signals are for conditions that are typically
fatal on most operating systems. (Note: if the program itself
used raise() to raise one of the C89- defined signals, then
returning from the signal handler -is- well defined.)
I would have to look up the details of the signals that C99 defines
to see if there are any of them for which returning from the signal
handler is well defined. C99 differs slightly from C89 in that
there are operations (such as overflow of a signed integer) that C89
just leaves the behaviour completely undefined, but for which C99
says that the behaviour is undefined or that the system may optionally
raise an implementation-defined signal. This is where the language
lawyers make their money, arguing about the difference between
behaviour that is -always- undefined, vs behaviour that the
implementation may define as being undefined!
--
"All human knowledge takes the form of interpretation."
-- Walter Benjamin
在文章< sl ******************* @ nospam.invalid>，
Antoninus Twink< no **** @ nospam.invalidwrote：
In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>在你的过程中发生了什么？虚拟地址空间，内存安排如下：
>What''s going on is that in your process''s virtual address space, memory
is arranged like this:
> -------------- ---------
| |
|堆栈|
| （向下长大）|
| |
-----------------------
| |
|免费记忆|
| （适用于|
|堆栈或堆）|
| |
-----------------------
| |
| HEAP |
| （向上成长）|
| |
-----------------------
>-----------------------
| |
| STACK |
| (grows downwards) |
| |
-----------------------
| |
| FREE MEMORY |
| (available for the |
| stack or heap) |
| |
-----------------------
| |
| HEAP |
| (grows upwards) |
| |
-----------------------
>因此，如果你的可用内存不足并溢出堆栈，你会发现坏事会发生。
>So if you run out of free memory and overflow the stack, you can see
that bad things will happen.
你真的是一个了不起的读者！我不知道你是怎么做到的！
*确定原来的海报现在已经确定了，并且
总是使用堆叠的系统向下增长
并且堆积增长。
在我现在正在使用的系统中不会发生这种情况（一个
通用系统，曾经是几个不同计算领域的市场领导者，并且它不会发生这种情况
当你开始处理线程时;一旦你开始考虑在哪里 - 完全共享
库被映射到内存中就不会发生这种情况并不常见......
-
有时候这是一种艰难的生活，最大的诱惑就是让它变得多么难以成为借口弱化。 - Walter Dean Myers
You truly are an amazing mind-reader! I don''t know how you do it!!
*Knowing* with certainty that the original poster is now and will
always be using a system on which the stack grows downwards
and the heap grows upwards.
It doesn''t happen that way in the system I''m using right now (a
general-purpose system that at one time was the market leader in
several different computing niches), and it doesn''t happen that way
when you start dealing with threads; and it isn''t unusual for it not to
happen that way once you start considering where -exactly- shared
libraries get mapped into memory...
--
"It''s a hard life sometimes and the biggest temptation is to let
how hard it is be an excuse to weaken." -- Walter Dean Myers
这篇关于内存分配：静态还是动态？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
