STL向量与列表：图形邻接列表最有效吗？

Question

在push_back时，列表占用大部分时间来分配内存。 另一方面，当需要调整大小时，向量必须复制它们的元素。 因此，哪个容器最适合存储邻接列表？

Answer 1

我不认为这可以绝对肯定地回答。 尽管如此，我估计一个载体至少有90％的可能性会更好。 邻接列表实际上倾向于支持向量而不是许多应用程序，因为邻接列表中的元素顺序（通常）不重要。 这意味着当你添加元素时，它通常是在容器的末尾，当你删除一个元素时，你可以先将它交换到容器的末尾，所以你只能在最后添加或删除。

是的，矢量必须在扩展时复制元素，但实际上这几乎不是一个重要的问题。 特别是，向量的指数扩展率意味着元素被复制的平均次数倾向于常数 - 并且在典型的实现中，该常量约为3。

如果你真的存在真正的问题（例如，复制元素非常昂贵），我在矢量后的下一个选择仍然不会是列表。 相反，我可能会考虑使用std :: deque。 它基本上是指向对象块的指针向量。 它很少需要复制任何东西来进行扩展，并且在罕见的情况下，它必须复制的只是指针，而不是对象。 除非你需要deque的其他独特功能（在两端的常量时间内插入/删除），矢量通常是更好的选择，但即使如此，deque几乎总是比列表更好的选择（即，矢量通常是第一个选择，deque一个相当接近的第二个，并列出相当遥远的最后）。

Answer 2

答案取决于用例。 PS @quasiverse - 当你“保留”的内存（隐式或显式）耗尽时，向量调用realloc

如果您有一个不断变化的邻接列表（插入和删除），列表将是最好的。 如果您有一个或多或少的静态邻接列表，并且大多数时候您正在进行遍历/查找，那么向量将为您提供最佳性能。

Answer 3

STL容器没有严格定义，因此实现方式各不相同。 如果你小心，你可以编写你的代码，这样它就不关心它是一个向量还是一个正在使用的列表，你可以试着看看哪个更快。 鉴于缓存效果等的复杂性，几乎不可能以任何精度预测相对速度。

Answer 4

您可以为此比较​​添加第三个选项：带有专用分配器的列表。

对固定大小的小对象使用分配器可以大大提高分配/释放的速度......

Answer 5

本教程网站建议使用列表数组，或者我猜你可以使用列表元素的向量：列表数组列表