为什么使用 vecS 作为 OutEdgeList 模板参数的 boost adjacency_list 在遍历时使边无效？

Question

我正在阅读有关adjacency_list的文档以及选择图形类型对 memory 消耗、big-O 运行时和描述符稳定性的影响。

引用第一个链接：

下表总结了哪些操作会导致描述符和迭代器失效。 表中EL是OutEdgeList的缩写，VL是VertexList的缩写。 Adj Iter 类别包括 out_edge_iterator、in_edge_iterator 和 adjacency_iterator 类型。
描述符和迭代器失效的更详细描述在每个操作的文档中给出。

我知道如果对VertexList使用vecS ，那么在remove_vertex()上所有顶点描述符都将被调整，以便它们仍然是连续的。

我不明白为什么显然使用vecS会导致边缘迭代使边缘描述符无效。

我是否正确理解了该表，因为它说“如果在directedS的adjacency_list图上使用vecS作为边列表类型，那么您不能稳定地迭代边，因为迭代它们会使边迭代器和边描述符无效” ？

如果我确实理解正确，请解释为什么会这样。 如果我理解有误，请说明使用vecS for Edge List的实际效果。
谢谢你。

Answer 1

正如您所怀疑的那样，您误读了它。

令人困惑的是列“Edge Iter”、“Vertex Iter”和“Adj Iter”是“Iterator”的缩写，而不是“iteration”。

单纯的迭代行为永远不会改变adjacency_list ，因此不能使描述符或迭代器无效。

在图模型中，描述符比迭代器（迭代器）更稳定。这实际上是描述符概念的关键原因。任何具有引用稳定性的容器选择器（即基于节点的容器）自然会具有迭代器稳定性（仅使迭代器无效到擦除的节点）。

该表很有用，因为对于“不可变”（或很少更改，经常查询）图的性能，可以通过选择连续存储（如 vecS）来大大增强，并且它们自然会施加更多限制性的无效规则（例如，向量可能会重新分配，从而使无效所有迭代器，但描述符可能在修改/插入索引之前保持稳定）。

提示

要对基本失效问题进行原始编译时检查，请考虑通过 const 引用获取图表。 这将消除意外修改的机会。 当然，在某些情况下，您真的想走边缘（为了性能）您想要对图形执行修改，并且您必须每次使用文档以确切了解适用于该修改的无效规则。