为什么STL容器使用复制来填充resize?

它节省了复杂性。我们当然需要复制构造的情况,默认构造可以建模为复制默认构造的对象。

性能损失可以忽略不计。写零和复制零的速度差不多。兼容性惩罚为零,因为所有容器都要求可复制性。另一方面,默认构造不是必需的。

emplace 安放 同时包含多个元素(如果你用的是 deque 安放 resize 不过。)

在你的情况下,也许你最好把 指针

关于在容器中复制;有什么选择?如果你不得不重新分配一个新的内存块来存储任何正在存储的东西,你必须以某种方式获取其中的现有数据!

对于这种行为,我能想到的唯一原因是容器支持插入,而插入需要一个副本。您应该能够创建一个容器,以类似于 deque (分页和非连续)默认值构造新元素。但是,您必须禁止在插入元素的同时指定整个容器—您可以修改在集合中构造的对象。

我的猜测是,没有人认为需要一个不支持插入和不实现值类型复制的集合。另一个注意事项是,您可能应该在关闭之前将其标记为wiki;)

标准容器定义了值类型上可复制和可分配的需求,这些需求足以支持容器和序列上的所有操作(您可能还希望它们对于关联容器具有可比性,但即使这样也不是必需的,因为您可以提供一个比较器)。

您所要求的是,对一组操作有一组需求,这些操作由容器的一部分加上序列中的某些内容(即1参数)组成 resize() 在那些永远不会移动其内容物的容器上, operator[] clear() 迭代器接口 *it = t ),以及对其余部分的另一组要求。标准库倾向于用另一种方式来实现这一点:选择一组涵盖几乎所有内容的公共需求,然后对少量功能有额外的需求(比如为了调用 调整大小()

容器的设计并没有考虑到你的特定操作集——复制和赋值是它们设计的内在功能,也就是包含放入其中的值,所以我推测在Stepanov看来,这不是“一点点功能”。因此更广泛的需求是存在的,因为抽象容器比您建议的ResizeableCollectionOfDefaultConstructedObjects更大。事实上,带走 而CollectionOfDefaultConstructedObjects几乎只是一个数组。我想STL和C++标准的设计者没有经常遇到你的用例,认为它值得抽象。