Range：：View：：Transform生成一个InputIterator，阻止使用std：：prev [英] ranges::view::transform produces an InputIterator preventing the use of std::prev

问题描述

考虑使用C++20中的Ranges库的以下代码：

#include <vector>
#include <ranges>
#include <iostream>

int main()
{
    std::vector<int> v{0,1,2,3,4,5,6,7};

    auto transformed = std::ranges::views::transform(v, [](int i){ return i * i; });

    std::cout << *std::prev(std::end(transformed));
}

得知(至少在GCC-10.3.0和GCC-12.0.0下)这个代码gets stuck in std::prev，我很惊讶。

由于lambda不返回左值引用，因此transformed范围迭代器被归类为输入迭代器(请参阅iterator_category选择views::transform)。然而，std::prevrequires迭代器至少是一个双向迭代器，所以我猜这段代码实际上是UB。在libstdc++中，对输入迭代器应用std::prev会导致此函数

template<typename _InputIterator, typename _Distance>
__advance(_InputIterator& __i, _Distance __n, input_iterator_tag)
{
    // concept requirements
    __glibcxx_function_requires(_InputIteratorConcept<_InputIterator>)
    __glibcxx_assert(__n >= 0);
    while (__n--)
        ++__i;
}

使用__n == -1调用，这解释了观察到的行为。

如果我们用手动迭代器递减替换std::prev，everything works fine。正在切换到std::ranges::prevworks, too。

现在，我不能对仅是一个视图的std::prev执行std::vector显然是荒谬的。虽然存在一个简单的解决方案，但我对标准库的新旧范围操作部分之间的这种意外相互作用感到非常担忧。因此，我的问题是：这是一个已知问题吗？在使用新范围时，我是否真的应该忘记所有不在std::ranges名称空间中的内容，并重写所有现有代码以确保它们可以与新范围一起使用？

推荐答案

根据C++17的计算，它不是一个随机访问迭代器。transform必须返回值而不是reference，而C++17的迭代器类别不允许任何高于InputIterator的值。

但根据C++20的规则，此类型是std::random_access_iterator，它允许在连续以下的任何迭代器/范围上使用类似代理的迭代器。

std::prev是C++20之前的工具，所以它按照C++20之前的规则工作。如果您需要使用C++20规则，则必须使用the C++20 equivalent: std::ranges::prev。

现在，我不能对std：：载体上的视图执行std：：prev显然是荒谬的。

不，这是必需的。与以前的C++版本相比，C++20概念化的迭代器类别限制较少。这意味着存在无法在C++20之前的代码中使用的迭代器，而可以在基于C++20范围的代码中使用。

这就是我们在ranges命名空间中为这些内容添加新函数的原因。

这篇关于Range：：View：：Transform生成一个InputIterator，阻止使用std：：prev的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！