为什么并行for_each需要前向迭代器？

Question

我正在设计一个遍历多个容器的迭代器，因此有一个代理对象作为返回类型。 因此，它可以做的最好是成为一个输入迭代器（这是因为前向迭代器需要reference是一个实际的引用类型，而对于输入迭代器来说这是不正确的）。

（让我说）简单的for_each就像我的迭代器的魅力一样。
但是，当我查看它的并行版本时，我看到它只接受前向迭代器。 因此，我不能使用一个复杂的迭代器来返回一个代理对象，这很烦人。
另一方面，我在网上查看了其他值得注意的实现，这并不像我最初想象的那样常见 - 例如，英特尔TBB为每个接受输入迭代器的提供了自己的并行。

我的问题是：为什么并行std::for_each不能与输入迭代器一起工作？
我看不出它们是前向迭代器的重点，因为乍一看它即使使用输入迭代器也应该工作正常。 我错过了什么？

Answer 1

由于你指出的原因，C ++ 17迭代器模型存在一个已知的缺陷，即代理迭代器只能是输入迭代器。 这有很多缺点。 并行算法不需要非代理迭代器，但它们肯定需要多次通过保证。 当前的迭代器类别模型将两者混为一谈。

对于C ++ 20范围，我们得到了iterator_concept概念，它是一个向后兼容的填充程序，可以正确支持代理迭代器。 例如，您可以使用input_iterator_tag的iterator_category ，但可以使用forward_iterator_tag的iterator_concept 。 新的ForwardIterator概念没有考虑该类别，它着眼于这个概念：

 template<class I> concept ForwardIterator = InputIterator<I> && DerivedFrom<ITER_CONCEPT(I), forward_iterator_tag> && Incrementable<I> && Sentinel<I, I>; 

并行算法是否会改变是一个我无法回答的不同问题。

Answer 2

C ++ 17迭代器概念将前向迭代器定义为最弱的迭代器形式，它需要在相同范围内运行多个迭代器。 也就是说，您可以复制前向迭代器，增加副本，但仍然可以通过原始迭代器访问原始值。

纯IntputIterator概念只需要单遍。 一旦递增迭代器，它的所有其他副本实际上都是无效的。

能够并行化for_each最终需要每次并行调用以获得一组独特的迭代器和值来进行操作。 这意味着迭代器必须是可复制的并且独立于其他迭代器。 这需要他们成为前向迭代器。

现在是的，这意味着你不能使用并行for_each代理迭代器，即使你的迭代器是相互独立的。 这只是C ++ 17迭代器概念模型的局限性。