什么时候std :: deque需要重新分配?

时间:2014-12-20 12:52:24

标签: c++ deque

据我所知std::deque将其元素存储在多个块中(尽管它依赖于实现,但这是我在大多数源代码中读到的),而不是std::vector。这些案例使用一块内存。

因此,std::vector作为插入的一部分遇到重新分配是非常合理的。但是,我无法解决任何需要重新分配std::deque的情况,因为当电流爆炸时,它只会重新开始使用新的内存块。

任何人都可以向我提供std::deque因执行某些操作而需要重新分配的情况吗?

2 个答案:

答案 0 :(得分:4)

  

任何人都可以向我提供std :: deque需要重新分配的情况   对其进行一些操作的结果。

在典型情况下,永远不要。虽然未指定deque的精确实现细节,但是为了保留迭代器/指针/引用无效*和算法要求,对于要求将现有内存块重新分配给更大或更小的任何场景都会发现实际应用。之一。

[特别关注指针/参考失效,因为它告诉我们更多关于内存中必须发生的事情。迭代器可以做出一些例外,将其有效性从deque]的内存表示中分离出来。

尝试将自己置于实施者的角度。你是如何实现push_frontpush_back和扩展resize这样的功能的方式,如果你曾经被诱惑,那么它不会使deque的任何现有指针无效重新分配内存块?

同样,为了保留重新分配现有内存块,保留pop_frontpop_back的类似要求并缩小resize(仅使指向已删除元素的指针无效)更小的尺寸?

陷阱部分,以及您可能找到最可能重新分配的地方,是插入deque的中间位置。这是指deque的所有指针都可以无效的地方,并且可以重新分配deque's内容(可能,不一定< EM>实际)。只有在这种特殊情况下,作为deque实现者​​,我们才能使指向仍然存在的元素的指针无效,我们甚至可以自由地重新分配任何现有的内存块。但是这种情况不太可能发生,因为高效的insert实现通常只是想要随机移动和移动元素,而不是实际重新分配它们所在的内存块。

所有这些要求结合起来将实施限制在Sutter所描述的类型中,即使他在那里有些邋and并掩盖了理论部分。它有点像C ++ 03代码经常理所当然地认为std::vector总是连续的,即使它未被指定,因为std::vector的算法和迭代器要求使得连续的表示相当漂亮这是唯一可行的选择。

因此从理论上讲,有人可能会在某种程度上在某个地方偷偷重新分配,同时符合这些要求。但在实践中,它几乎是不可能的,而且绝对不切实际,所以你很难找到这样的deque实现。

答案 1 :(得分:0)

我想到的一件事是当你在双端队列上插入并且插入需要去的页面已满时会发生什么? cplusplus.com说明关于deques的插入函数

If the insertion happens at the beginning or the end of the sequence, all iterators 
related to this container are invalidated, but pointers and references remain valid, 
referring to the same elements they were referring to before the call. If the 
insertion happens anywhere else in the deque, all iterators, pointers and references 
related to this container are invalidated.

真正引起我注意的部分是,所有内容都无效的是插入位于中间,对我来说听起来像是基础数据结构正在发生的事情。我不确定它是否是重新分配,但它至少是一个shift-copy-insert。