c++ - view::join 是否需要可复制的内部范围？为什么？

Question

假设我们有

cppcoro::generator<int> gen_impl(int in) {
  const auto upper = in + 10;
  for (; in < upper; ++in)
    co_yield in;
}

cppcoro::generator<cppcoro::generator<int>> gen() {
  for (int n = 1; n < 100; n += 10)
    co_yield gen_impl(n);
}

所以我们可以很好地迭代内部范围

  for (auto&& row : gen() ) {
    for (auto n : row)
      std::cout << n << ' ';
    std::cout << '\n';
  }

注意:range-for on ref 是必需的，因为 cppcoro::generator 不允许复制(已删除复制 ctor)

打印

1 2 3 4 5 6 7 8 9 10
11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30
31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50
51 52 53 54 55 56 57 58 59 60
61 62 63 64 65 66 67 68 69 70
71 72 73 74 75 76 77 78 79 80
81 82 83 84 85 86 87 88 89 90
91 92 93 94 95 96 97 98 99 100

但是当我们尝试用 view::join 来“扁平化”时

auto rng = gen();
for (auto n : rng | ranges::view::join) {
  std::cout << n << '\n';
};

似乎 view::join 需要 可复制 内部范围？

In file included from <source>:3:

In file included from /opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/view.hpp:38:

In file included from /opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/view/for_each.hpp:23:

/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/view/join.hpp:320:50: error: call to deleted constructor of 'cppcoro::generator<cppcoro::generator<int> >'

                    return join_view<all_t<Rng>>{all(static_cast<Rng&&>(rng))};

                                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/view/view.hpp:112:21: note: in instantiation of function template specialization 'ranges::v3::view::join_fn::operator()<cppcoro::generator<cppcoro::generator<int> > &, false, nullptr>' requested here

                    v.view_(static_cast<Rng&&>(rng))

                    ^

/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/utility/functional.hpp:731:42: note: in instantiation of function template specialization 'ranges::v3::view::view<ranges::v3::view::join_fn>::pipe<cppcoro::generator<cppcoro::generator<int> > &, ranges::v3::view::view<ranges::v3::view::join_fn> &, false, nullptr>' requested here

            pipeable_access::impl<Pipe>::pipe(static_cast<Arg&&>(arg), pipe)

                                         ^

<source>:35:21: note: in instantiation of function template specialization 'ranges::v3::operator|<cppcoro::generator<cppcoro::generator<int> > &, ranges::v3::view::view<ranges::v3::view::join_fn>, false, nullptr>' requested here

  for (auto n : rng | ranges::view::join) {

                    ^

/opt/compiler-explorer/libs/cppcoro/include/cppcoro/generator.hpp:174:3: note: 'generator' has been explicitly marked deleted here

                generator(const generator& other) = delete;

                ^

/opt/compiler-explorer/libs/rangesv3/trunk/include/range/v3/view/join.hpp:76:36: note: passing argument to parameter 'rng' here

            explicit join_view(Rng rng)

                                   ^

是什么导致它没有被编译？

range-v3 或 cppcoro 是否有任何错误？

只有不兼容的设计决策？

godbolt (满)

Answer 1

在 range-v3 中，仅移动 View 是可以的。实现较晚，可能仍然存在错误，但这不是这里发生的事情。

第一个问题是您正在尝试调整 cppcoro::generator 类型的左值。这里:

auto rng = gen();
for (auto n : rng | ranges::view::join) {

由于生成器是 View ，join View 将要复制它。它不能，因为它不可复制。

您可以通过将生成器移入来解决此问题:

auto rng = gen();
for (auto n : std::move(rng) | ranges::view::join) {

然后你会遇到下一个问题，即 generator<generator<int>> 的引用类型是 const generator<int>& ，你又遇到了同样的问题:join想要在迭代内部生成器时保留内部生成器的拷贝，但它无法制作拷贝。

解决方法有点难看:更改生成器以返回非常量左值引用:

cppcoro::generator<cppcoro::generator<int>&> gen() {
  for (int n = 1; n < 100; n += 10) {
    auto tmp = gen_impl(n);
    co_yield tmp;
  }
}

然后是 std::move每个内部范围都带有 move观点:

auto rng = gen();
for (auto n : std::move(rng) | ranges::view::move | ranges::view::join) {
  std::cout << n << '\n';
}

结果编译。它是否运行取决于 cppcoro 如何优雅地处理有人偷走它安全地藏在协程的 Promise 类型中的值的胆量。

https://godbolt.org/z/mszidX

关于 future 的注释std::view::join :

join与 C++20 一起发布的 View 略有不同。如果外部范围的引用类型是真正的引用(如本例所示)，它不会尝试复制它所引用的 View 。这意味着在 C++20 中，您将不需要丑陋的 view::move破解。

但是，C++20 View概念目前需要可复制性，所以这个解决方案仍然行不通。在 C++20 发布之前，我们有一个 TODO 项目来放宽这一点，但不知道委员会会如何喜欢这个想法。