为什么 std::advance 不返回结果迭代器？答案

【问题标题】：Why does not std::advance return the resulting iterator?为什么 std::advance 不返回结果迭代器？
【发布时间】：2026-02-14 20:50:02
【问题描述】：

目前，std::advance 是这样设计的：

template< class InputIt, class Distance >
void advance( InputIt& it, Distance n );

但是，我经常发现自己想要类似的东西：

template< class InputIt, class Distance >
InputIt advance( InputIt it, Distance n );

那么，当前设计背后的基本原理是什么？这是出于某种性能考虑吗？请注意，std::next 和 std::prev 确实会返回结果迭代器。

【问题讨论】：

我相信这种设计需要支持输入迭代器。 std::next 和 std::prev 相应地需要正向和双向迭代器。
我相信他们没有想到要这样设计它......就像许多其他东西一样。
std::next 不会更改传递给它的迭代器，它会返回另一个指向集合中下一个元素的迭代器。这不是输入迭代器的选项。
请注意，C++ 并不禁止您编写自己的std::advance 或在其之上的版本。
将advance 视为高级便利函数（如next）使用的底层低级实现抽象。他们两个都有一席之地。

标签： c++ iterator c++-standard-library

【解决方案1】：

没有技术原因阻止它返回对输入值的引用，并且任何合理的编译器都应该能够在不使用时优化返回值。所以如果他们愿意，他们可以这样做。

我认为从 API 设计的角度来看，他们的选择是有意义的 - std::prev 和 std::next 采用迭代器并分别返回指向上一个或下一个元素的不同迭代器，无需修改输入.

std::advance 另一方面修改输入。如果它返回了对输入迭代器的引用，那么对于返回副本而不就地修改输入的函数可能会感到困惑。这可能很危险。

请注意std::advance 与InputIterators 一起使用，其中包括迭代具有副作用的迭代器（例如从流中读取的迭代器），但std::prev 和std::next 仅与ForwardIterators 一起使用，没有副作用。

因此返回一个单独的值（如std::prev 和std::next）将是一个坏主意 - 您最终会在同一个流上使用两个迭代器，这可能会相互影响.

【讨论】：

这作为解释没有意义——你只是在重复明显的事实。整个答案归结为“他们本可以做到，但他们没有”。
@BartoszKP 他们本可以这样做，但他们没有这样做，因为这不是一个好主意。我的回答解释了为什么这是一个坏主意。
例如，第三段是适用于 any 函数的琐事，而不仅仅是std::advance。如果std::prev 引用了一个引用，你可以说完全一样的事情——返回一个引用可能会与一个返回副本而不修改输入的函数混淆。只有关于输入和转发迭代器的段落（您刚刚添加的）是相关的。所以，现在看起来没问题（尽管我会删除所有其他部分，因为它们只是噪音而且很难找到重点，仅在第 4 段中） - 我将删除我的 cmets。干杯！
不知何故我认为 std::prev 不能在 ForwardIterator 上工作（需要 BidirectionalIterator）

【解决方案2】：

主要原因，如 cmets 部分所述，InputIterator 不保证在递增迭代器后，任何先前的迭代器仍然有效：

InputIterators 只保证单遍算法的有效性：一旦 InputIterator i 增加，其先前值的所有副本都可能无效。

因此，如果std::advance 返回一个副本，调用者可能会得到两个迭代器，其中一个可能无效。带有引用的接口表明这不是输入迭代器的使用方式。

另一方面，std::prev 和std::next 采用BidirectionalIterator，其中满足ForwardIterator 的要求：

与 InputIterator 和 OutputIterator 不同，它可以用于多通道算法。

因此，您可以移动迭代器，同时仍保留其先前位置的副本。

Here 是一个很好的表格，它清楚地展示了不同迭代器概念之间的关系。

当然有人可能会争辩说，调用者应该知道 InputIterator 是如何工作的，并且应该允许他们方便地选择适合他们当前需要的版本。 dyp 在 cmets 部分提出了此类问题的一个示例：http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2353。

然而，取悦每个人总是会导致接口中方法数量的爆炸式增长。

该链接表明，现在是一种待达成共识的状态。

【讨论】：