为什么 Stack<T> 和 Queue<T> 没有容量属性，而 List<T> 有？答案

【问题标题】：Why don't Stack<T> and Queue<T> have Capacity property while List<T> does?为什么 Stack<T> 和 Queue<T> 没有容量属性，而 List<T> 有？
【发布时间】：2013-06-24 16:13:11
【问题描述】：

Capacity 属性在 List 中是否比在 Stack 和 Queue 等其他集合中更有用？或者还有其他方法可以获取 Stack 或 Queue 的容量吗？

【问题讨论】：

Queue 和 Stack 都具有类似于容量的 Count 属性，但不知道为什么它们没有包含容量属性。 msdn.microsoft.com/en-us/library/fy0wwyz4.aspx
@JamieHennerley：计数和容量不相同。 Count 是您存储在结构中的项目数量。 Capacity 是内部数组可以存储的项目数量。 Capacity 永远不会小于 Count。通常大于Count。如果它等于Count 并且您想添加另一个项目，则内部数组将被复制到具有更大容量的新数组中。

标签： c# list stack queue capacity

【解决方案1】：

我认为List有Capacity属性而Stack和Queue没有的原因是这些类型的正常用法不同。

对于List，使用大量值填充它是相当常见的，即使在它创建后的一段时间也是如此。提供 Capacity 属性（和构造函数参数）有助于减少在向列表中添加大量项目时将完成的重新分配次数。

另一方面，Stack 和 Queue 往往不会在创建后立即将大量项目添加到其中。

大概微软认为不值得添加 Capacity 属性，因为它不会被大量使用。

但是，请注意Queue does have a constructor that allows you to specify an initial capacity 和so does Stack。

另请注意，这两个类也有一个TrimExcess() 方法，如下面的@drch 所述。

所以微软认为它在构建时会很有用，但后来就没有用了——所以他们只在构造函数中添加了容量功能。

（顺便说一下，我刚刚快速检查了我们的代码库，似乎我们唯一一次使用List 的容量实际上是在构建时。所以也许如果微软现在正在设计 List，他们也可以省略 List 的 Capacity 属性...）

【讨论】：

如果内部数组未满 90%，还有 TrimExcess() 将容量设置为当前计数。

【解决方案2】：

Stack<T> 或 Queue<T> 不会公开此信息。这些信息甚至没有显式存储在这些类中，只是以内部数组长度的形式隐式存储。

您唯一的选择是使用反射来访问数组并获取它的长度。

【讨论】：

【解决方案3】：

Stack 和 Queue 分别是 LIFO 和 FIFO 结构。

在这两种情况下，您（作为 API 的使用者）通常只需要知道如何将数据放入结构中，以及如何再次取出数据。您不关心数据结构的长度，只关心push 和pop。

如果您出于任何原因需要获取容量（可能是有界堆栈/队列？），那么最好对最终用户隐藏该细节并实现您自己的堆栈/队列结构。

【讨论】：

但是 Stack 和 Queue 都有 Count 属性...Capacity 属性仅用于优化目的（大概也适用于 Stack 和 Queue 以及 List）。
这很奇怪。堆栈和队列通常都使用链表实现（其中容量无济于事），但这是实现细节泄漏的一个示例。也许这就是重点，如果定义了Capacity，这将为底层实现提供一个重要线索。
嗯，你可以使用正确的构造函数设置List和Queue的初始容量。参数名偶是capacity...
List 是一种暗示底层实现的具体类型（“表示可以通过索引访问的强类型对象列表”），因此具有容量似乎很好。另一方面，LinkedList 没有提供这样的构造函数。
确实如此，但重点是Stack 和Queue do 允许您指定容量。