为什么并行的for_each需要正向迭代器? [英] Why does the parallel for_each require forward iterators?

问题描述

我正在设计一个遍历多个容器的迭代器，因此将代理对象作为返回类型.因此，最好的办法是成为输入迭代器(这是因为前向迭代器要求 reference 是实际的引用类型，而就我而言，这对输入迭代器而言并非如此.参见).

I was designing an iterator that goes over multiple containers and thus has a proxy object as a return type. Because of that, the best it can do is to be an input iterator (this is because forward iterators require reference to be an actual reference type, while this isn't true for input iterators as far as I see).

(让我说)普通的 for_each 就像我的迭代器一样具有魅力.
但是，当我查看其并行版本时，发现它仅接受转发迭代器.因此，我不能使用复杂的迭代器来返回代理对象，这很烦人.
另一方面，我在网上寻找其他值得注意的实现，这并不像我最初想象的那么普遍-例如，英特尔®TBB为每个接受输入迭代器的设备提供了自己的并行处理.

The (let me say) plain for_each works like a charm with my iterator.
However, when I looked at its parallel version, I saw that it accepts only forward iterators. Therefore I cannot use a complex iterator that returns a proxy object with it and this is annoying.
On the other side, I looked online to other notable implementations and this isn't as common as I thought initially - eg Intel TBB offers its own parallel for each that accepts input iterators.

然后我的问题是:为什么并行的 std :: for_each 不能与输入迭代器一起使用?
我看不到它们是正向迭代器的意义，因为乍一看，即使使用输入迭代器，它也可以正常工作.我想念什么?

My question is then: why doesn't the parallel std::for_each work with input iterators?
I cannot see the point of them being forward iterators, because at first glance it should work fine even with input iterators. What am I missing?

推荐答案

由于您指出的原因，C ++ 17迭代器模型存在一个已知缺陷，即代理迭代器只能是输入迭代器.这有很多缺点.并行算法不需要非代理迭代器，但是肯定需要多遍保证.并且当前的迭代器类别模型将两者融合在一起.

There is a known flaw with the C++17 iterator model in that proxy iterators can only ever be input iterators, for the reasons you point out. This has lots of downsides. The parallel algorithms don't need non-proxy iterators, but they definitely need the multi-pass guarantee. And the current iterator category model conflates the two.

在C ++ 20范围内，我们得到 iterator_concept > ，这是向后兼容的填充程序，可正确支持代理迭代器.例如，您可以使用 input_iterator_tag 的 iterator_category ，但可以使用 forward_iterator_tag 的 iterator_concept .新的 ForwardIterator 概念并不关注类别，则查看概念:

With C++20 ranges, we get this idea of iterator_concept, which is a backwards-compatible shim to properly support proxy iterators. You can have an iterator_category of input_iterator_tag but an iterator_concept of forward_iterator_tag, for instance. The new ForwardIterator concept does not look at the category, it looks at the concept:

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

并行算法是否会改变是另一个我无法回答的问题.

Whether or not the parallel algorithms will change is a different question that I can't answer.

这篇关于为什么并行的for_each需要正向迭代器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！