时间戳

首页 > 解决方案 > C ++ 23中default_constructible范围适配器的含义是什么？

c++ - C ++ 23中default_constructible范围适配器的含义是什么？

问题描述

从 C++23 开始，views 不再需要是default_constructible. views::filter对于和等范围适配器views::transform，它们的默认构造函数被重新定义为：

template<input_­range V, indirect_­unary_­predicate<iterator_t<V>> Pred>
  requires view<V> && is_object_v<Pred>
class filter_view : public view_interface<filter_view<V, Pred>> {
private:
  V base_ = V();                              // exposition only
  copyable-box<Pred> pred_;                   // exposition only
public:
  filter_view() requires default_­initializable<V> && default_­initializable<Pred> = default;
};

并且由于p2325r3中的默认构造函数ref_view已被删除，这表明应用于 lvalue的范围适配器不再是：rangestd::vector default_constructible

std::vector v{1, 2, 3};
auto r = v | std::views::filter([](auto) { return true; });
decltype(r){}; // ok in C++20, error in C++23

只有当范围适配器被应用到default_constructible views 中时，例如std::string_viewor views::iota(0)，返回的视图才可以是default_constructible：

auto r = std::views::iota(0) | std::views::filter([](auto) { return true; });
decltype(r){}; // ok in C++20 and C++23

但是对于这些情况，即使可行，我也真的想不出制作这些views的用例。default_constructible如果我们view默认构造a，就意味着我们构造了一个empty view，对empty s应用范围适配器显然是没有意义view的：

constexpr auto r = std::views::iota(0, 10)
                 | std::views::transform([](auto x) { return x; });
static_assert(!std::ranges::empty(r));
// views::iota is default-constructible, so r is also default-constructible
static_assert( std::ranges::empty(decltype(r){}));

在我看来，C++20 中范围适配器的默认构造函数只是为了满足view，由于view不再需要default_constructible在 C++23 中，因此这些适配器的默认构造函数不需要存在。

为什么这些范围适配器的默认构造函数在 C++23 中没有被删除，而是变成了约束函数？真的有需要它的情况default_constructible吗？这背后的考虑是什么？

标签： c++std-rangesc++23

解决方案

本文之前的现状是视图必须是默认可构造的，即使这不是视图可以满足的有意义的要求，导致它具有只能分配给的单一状态。这不是很有用（而且确实有害），这就是删除该要求的原因。

但是既然视图可以简单地默认构造，那么问题是何时应该使范围适配器默认构造。这个问题的答案更直接：如果可以的话，为什么不让它默认可构造呢？

如果您正在transform查看一个视图，V则它是默认可构造的（并且可能V以具有有意义状态的方式默认可构造 - 这并非不可行：默认构造string_view是一个有效的空范围）并且您的函数F也是默认的可构造的（例如，任何无捕获的 lambda 在 C++20 中），那么transform_view<V, F>实际上也应该是默认可构造的。确实没有太多理由不这样做，有条件地提供该构造函数实际上是免费的，而且它不会造成伤害。

因此，在不提供默认构造函数和有条件地提供默认构造函数之间，后者似乎是一个对用户更友好的选择。

否则，从库的角度来看，您必须能够以某种方式保证默认构造这样的范围适配器永远不会有用......我不确定你能做到吗？

请注意，这不是 C++23 的新库功能，而是针对 C++20 的缺陷。

推荐阅读