blocks|key|2822676|text|从堆栈中分配内存非常简单。你只需要调整堆栈指针。在x64上，这是一个单一的指令：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2822677|sub+rsp,+size|code-block|syntax|javascript|2822678|堆分配需要一些内存管理机制来查找足以容纳数组的块，选择一个块，将其标记为某个位置，并可能要求OS通过增加进程的地址空间来分配更多内存页。它比基于堆栈的分配要复杂得多。|2822679|因为我没有这本书，所以我不知道它使用的是什么上下文。这可能意味着数组在分配后不会在堆中移动。|2822680|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Allocating memory off the stack is very simple. You just need to adjust the stack pointer. On x64, it's a single instruction:

<pre><code>sub rsp, size
</code></pre>

Heap allocation requires some memory management mechanism to look for a block large enough to hold the array, choose a block, mark it as allocated somewhere, and possibly asking the OS to allocate more memory pages by growing the address space of your process. It's much more complicated than stack-based allocation. 

Re "fixed", since I don't have the book, I don't know the context it's using that word. Probably it means the array will not move in the heap after allocation.

blocks|key|1178772|text|如果堆可以增长以适应每一个新的分配，那么创建一个数组可能会很快。如果堆是“固定的”，那么我们需要在堆中找到空间，正如Mehrdad解释的那样，这需要做一些重要的工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1178773|不过，我不太清楚这句话的结尾：|1178774|固定堆动态数组的缺点是它们从堆栈.分配数组所需的时间更长。|offset|length|style|BOLD|1178775|您肯定不会“从堆栈”分配堆内存。|1178776|entityMap^0|0|0|L|8|0|0|G|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@$F|Q|G|R|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@$F|T|G|U|H|I]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|M|$]]

If the heap could be grown to accommodate each new allocation then creating an array could be quick. If the heap is "fixed" then we need to find space within the heap and as Mehrdad has explained that requires non-trivial work.

I don't quite parse the end of the sentence though:

The disadvantage of fixed heap-dynamic arrays is that they take longer time to allocate array from stack.

You don't allocate heap memory "from stack" surely.

blocks|key|1179619|text|术语来源于三个正交概念：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1179620|数组的大小是否可以在其初始分配后更改，还是永远保持不变，“固定”。|unordered-list-item|1179621|数组所在的位置:堆栈或堆内存。|1179622|如果分配大小是在运行时“动态”或编译时确定的。|1179623|entityMap^0|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|$]]|$1|E|3|F|5|D|7|M|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|N|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|O|8|@]|9|@]|A|$]]]|J|$]]

The terminology comes from three orthogonal concepts: 

<ul>
<li>Whether the size of the array can change after its initial allocation, or stays the same size forever, "fixed". </li>
<li>Where the array is located: stack or heap memory.</li>
<li>If the allocation size is determined at runtime "dynamic", or compile-time. </li>
</ul>

blocks|key|1178803|text|ergosys的回答是完全正确的。这个问题是我为什么讨厌Sebesta的又一个例子。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1178804|在许多现代系统中，从堆中分配对象使用与从堆栈分配相同的指令:测试和增加堆指针。(的确，合并堆栈分配比合并堆分配要容易，但也比可以完成的要容易。)执行这种分配的编译器包括光荣的格拉斯哥Haskell编译器和新泽西标准ML。SML/NJ已经在这种情况下部署了20多年，所以您认为Sebesta现在可能已经开始使用它了。|offset|length|1178805|摘要:和往常一样，Sebesta过度推广了。可能有理由选择堆栈分配，但这个故事比Sebesta似乎意识到的要复杂得多，或者比Mehrdad在他的回答中描述的要复杂得多。从理解更深层次的故事开始，一个很好的地方是使用安德鲁·阿佩尔关于堆栈分配的论文。|style|BOLD|1178806|entityMap|0|LINK|mutability|MUTABLE|url|http://www.haskell.org/ghc/|1|http://www.smlnj.org/|2|http://www.cs.princeton.edu/~appel/papers/45.ps^0|0|2C|H|0|2U|7|1|0|9|C|2Z|G|2|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]|$D|10|E|11|1|12]]|A|$]]|$1|F|3|G|5|6|7|13|8|@$D|14|E|15|H|I]]|9|@$D|16|E|17|1|18]]|A|$]]|$1|J|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]|T|$5|M|N|O|A|$P|U]]]]

The answer from ergosys has the terminology exactly right. The question is yet another example of why I hate Sebesta.

In many modern systems, allocating an object from the heap uses exactly the same instructions as allocating from the stack: test and increment the heap pointer. (It it true that it is easier to combine stack allocations than to combine heap allocations, but than can be done too.) Compilers that do this kind of allocation include the <a href="http://www.haskell.org/ghc/" rel="nofollow noreferrer">Glorious Glasgow Haskell Compiler</a> and <a href="http://www.smlnj.org/" rel="nofollow noreferrer">Standard ML of New Jersey</a>. SML/NJ has been deployed in this condition for over 20 years, so you think Sebesta might have picked up on it by now. 

Summary: Sebesta is overgeneralizing, as usual. There may be reasons to prefer stack allocation, but the story is far more complicated then Sebesta seems to realize, or than Mehrdad describes in his answer. A good place to start with understanding the deeper story is with <a href="http://www.cs.princeton.edu/~appel/papers/45.ps" rel="nofollow noreferrer">Andrew Appel's paper about stack allocation</a>.

In programming languages concept,

Sebesta's book states that (Ninth ed., 284):

The disadvantage of fixed heap-dynamic arrays is that they take longer time to allocate array from stack. 

How can we analyze this statement? What is the difference between fixed heap-dynamic and heap-dynamic arrays. What does that fixed word stand for?

Performance btw. Stack-Heap Dynamic Arrays

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

在程序设计语言概念中，Sebesta的书说(第九版，284)：固定堆动态数组的缺点是它们从堆栈中分配数组所花费的时间更长。我们如何分析这一说法？固定的堆动态数组和堆动态数组的区别是什么？这个固定的词代表什么？

问表演方面。堆栈堆动态数组
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问表演方面。堆栈堆动态数组EN