我应该使用std:：list还是有更好的方法？ 我现在正在用C++编写二维几何编辑器。我有用户位置节点。可以通过选择2个节点来绘制直线和圆弧

现在，我将节点存储在std:：deque容器中（直线和圆弧也是如此），因为我想将节点的地址存储到每条直线/圆弧中。当我实现移动节点的功能时，这使得编码非常方便。如果我要将实际节点存储在每条直线/圆弧的内部，那么当我想要移动节点时，我必须迭代整个直线和圆弧结构，以找到我刚刚移动的节点并更新参数。此选项不是表上的选项。因此，需要能够在每条线/弧内存储节点的地址

但是，我遇到了一些需要删除节点的问题。查看参考手册，似乎对于所有指针，当您从deque中删除一个元素时，这些指针都无效（除非该元素位于开头或结尾。为了讨论起见，我将不考虑这种情况）。这导致了擦除的问题，因为现在，当一个节点被擦除并且程序最终崩溃时，所有的线/弧都会重新连接到不同的节点，或者根本不会绘制

继续在线查看，我发现std:：list（从我阅读文档的理解来看）在删除其中一个元素时不会使任何指针或引用无效。这似乎是解决我问题的一个很好的办法

然而，我一直在研究堆栈溢出，以了解使用列表与开发工具的优缺点。而且似乎更倾向于使用deque而不是list。似乎列表的访问速度比deque慢。这并不好，因为我不确定用户希望绘制多少节点。据我所知，几何体中可能有10000多个节点，如果用户想要移动节点，我不希望用户必须等待30秒，程序才能遍历所有元素以找到要删除的节点

因此，一方面，deque的速度要快得多，但一旦删除元素，所有指针和引用都将失效。另一方面，std:：list允许我删除我想要的任何元素，而不会使任何指针和引用无效，但与deque相比速度较慢

我正在考虑切换到列表，因为即使列表速度较慢，如果我无法在不使指针和引用无效的情况下删除元素，那么如果程序不工作，在速度方面也没有什么好处

然而，在我的情况下，使用列表是最好的选择吗？有什么方法可以使用deque吗？还是有第三种选择我没有考虑

编辑：

我忘了提。我不喜欢列表的一件事是无法直接获取元素的数据（在std:：deque和vector中，我可以使用at函数访问元素）。这对我的代码来说不是什么大问题。但它确实使事情变得方便。例如，当用户在创建直线/圆弧时选择节点时，代码会在整个节点列表上进行迭代，以确定选择了哪个节点，然后，对于第一次选择，将索引存储到变量（称为firstNodeIndex）中。对于第二个节点，它执行相同的操作，但当两个变量（firstNodeIndex和secondNodeIndex）都是可行的数字时，则调用用于创建线/弧的函数，该函数使用两个存储的索引重新访问节点列表以获取节点的地址。如果要使用列表，我必须将两个节点的地址存储在变量中，然后创建一些附加逻辑，以确保包含两个节点地址的两个变量是可行的选项

另一种替代解决方案是再次遍历整个节点列表，以获取选定的节点（每个节点内都有一个变量，表示已选定）。但考虑到std:：list的局限性，我担心这可能不是一个好主意

我有点赞成我的第一种方法，但如果需要或者有更好的方法，我愿意改变

我想随机添加和删除项目吗

set, list, map, multimap and unordered versions of same

我是否希望能够命名单个项目并快速找到它们

map, set, multimap and unordered versions of same

我存储的东西是否有可变数据，或者是否比它的名称（键）更详细

我需要按顺序说出这些项目吗

yes: map, no: unordered_map

---

所以，您的问题是，在插入或删除元素时，您不希望迭代器失效，但希望数据结构更快

只有当您必须频繁迭代所有元素时，链表才会变慢。In不利用vector或deque等连续数据访问。列表中的线性搜索也很慢

我也有类似的情况。以下是一些选项：

使用列表并尽量避免线性搜索。看看链表的内存访问速度是否会显著影响您的性能，如果不会，请使用它

使用地图或集合。与列表中的cons相同，但search除外，它是O（logn）。或者，如果不关心元素的排序，可以使用无序版本

使用非标准数据结构，如。如果您不关心插入的顺序，这可能是您最好的选择

创建自己的类似于deque的数据结构，它不会使迭代器失效（使用skipfields或将自由元素存储在某处）。我不推荐它，因为不管怎样，您可能最终会编写类似于

plf:：colony

的东西

---

根据我的（被否决的？）答案-使用地图。将节点id映射到节点。映射中的插入和删除不会使迭代器无效浏览plf:：colony，这似乎是一个可行的选择。我只需要确保没有插入顺序很重要的情况（wh

yes: map, no: unordered_map