容器容器设计不好吗?

时间:2012-03-06 09:04:16

标签: c++ containers

我需要一个容器容器,如:

class Widget {
  ...
};
...
std::vector<std::list<Widget> > widgets;

因为STL容器在其中复制对象,并且复制容器并不是一个便宜的操作,我认为这个容器容器可能导致效率非常差,因此设计不好。 我想知道我是对的。如果是,我应该使用容器指针容器还是其他东西? 感谢

P.S。

谢谢你们,现在我知道它是否是一个糟糕的设计取决于我如何使用它。

因此,如果我知道会在list中插入多少vector(最多),然后使用vector::reserve来避免vector重新分配,之后我只会查询其中的物体,这可能是一个很好的设计。

另一方面,如果我需要偶尔将list插入vector,这可能会导致效率非常低。

我是对的吗?

3 个答案:

答案 0 :(得分:4)

设计不错。这是你使用它的方式,可能是糟糕的设计。如果您的代码需要经常进行深度复制并且您实施std::vector<std::list<Widget> *> widgets,但仍需要深层复制,则与您正在执行的操作没有太大区别。

例如,如果您经常查询向量中的list的某些成员,由于向量的紧凑性,这可能实际上是好的设计,因为内存接近。

具有C ++ 11支持的现代编译器具有移动语义,通常移动数据而不是复制数据。所以我不会太担心矢量重定位或移位。 “移动”仍然可以由较旧的编译器使用std::swap完成,只要它比复制更有意义。

答案 1 :(得分:1)

不,为什么会这样?

正确使用它们不会成为瓶颈,而不是“简单”的STL容器。

错误地使用(设计明智的)他们当然会像你说的那样做,行动效率非常低。

对于您的特定问题,您可能希望将指针而不是对象存储为数据。

答案 2 :(得分:1)

我认为您的设计问题的答案主要取决于您无法看到的项目的特殊性。您是否需要存储值(并管理小部件的生命周期)或仅需要参考?

请注意,std :: vector仅在复制向量时复制元素。否则,当您只需要增加向量容量时,它使用通常便宜的元素移动构造函数。