我正在设计一个遍历多个容器的迭代器，因此有一个代理对象作为返回类型。因此，它最多只能成为一个输入迭代器（这是因为前向迭代器需要reference是一个实际的引用类型，但据我所知，这对于输入迭代器来说并非如此）。
（让我说）简单for_each与我的迭代器一起工作就像一个魅力。
然而，当我查看它的并行版本时，我发现它只接受前向迭代器。因此，我无法使用返回代理对象的复杂迭代器，这很烦人。
另一方面，我在网上查看了其他著名的实现，这并不像我最初想象的那么常见 - 例如，英特尔 TBB 为每个接受输入迭代器的并行提供了自己的并行。
我的问题是：为什么并行不std::for_each使用输入迭代器？
我看不出它们是前向迭代器的意义，因为乍一看，即使使用输入迭代器，它也应该可以正常工作。我缺少什么？
由于您指出的原因，C++17 迭代器模型存在一个已知缺陷，即代理迭代器只能是输入迭代器。这有很多缺点。并行算法不需要非代理迭代器，但它们确实需要多通保证。当前的迭代器类别模型将两者混为一谈。
对于 C++20 范围，我们得到这样的想法iterator_concept http://eel.is/c++draft/iterator.concepts，这是一个向后兼容的填充程序，可以正确支持代理迭代器。你可以有一个iterator_category of input_iterator_tag but an iterator_concept of forward_iterator_tag， 例如。新的ForwardIterator http://eel.is/c++draft/iterator.concept.forward概念不看类别，而是看概念：
template<class I>
concept ForwardIterator =
InputIterator<I> &&
DerivedFrom<ITER_CONCEPT(I), forward_iterator_tag> &&
Incrementable<I> &&
Sentinel<I, I>;
并行算法是否会改变是另一个我无法回答的问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
