C ++ 20 std :: ranges :: sort应该不需要支持std :: vector <bool>吗？

问题描述

我注意到std::ranges::sort无法对std::vector<bool>进行排序：

<source>:6:51: error: no match for call to '(const std::ranges::__sort_fn) (std::vector<bool,std::allocator<bool> >)'
6 |   std::ranges::sort(std::vector{false,true,true});
  |   

可以吗？我们是否需要为std::ranges::sort专门化std::vector<bool>？是否有有关委员会如何考虑的信息？

解决方法

正确。

通常，std::ranges::sort无法对代理引用进行排序。直接原因是sort要求sortable（令人惊讶，对），如果我们遵循这一链条，则要求permutable，要求indirectly_movable_storable，要求indirectly_movable，要求indirectly_writable indirectly_writeable。

template<class Out,class T> concept indirectly_writable = requires(Out&& o,T&& t) { *o = std::forward<T>(t); // not required to be equality-preserving *std::forward<Out>(o) = std::forward<T>(t); // not required to be equality-preserving const_cast<const iter_reference_t<Out>&&>(*o) = std::forward<T>(t); // not required to be equality-preserving const_cast<const iter_reference_t<Out>&&>(*std::forward<Out>(o)) = std::forward<T>(t); // not required to be equality-preserving }; 是一个非常特殊的概念。

const_cast<const iter_reference_t<Out>&&>(*o) = std::forward<T>(t);

我想特别提请您注意：

struct C
{
    explicit C(std::string a) : bar(a) {}    
    std::string bar;
};

int main()
{
    std::vector<C> cs = { C("z"),C("d"),C("b"),C("c") };

    ranges::sort(cs | ranges::view::transform([](const C& x) {return x.bar;}));

    for (const auto& c : cs) {
        std::cout << c.bar << std::endl;
    }
}

等等，我们需要 const 可分配性吗？

---

这个特殊问题历史悠久。您可以从#573开始，其中用户演示了此问题：

cs

当然期望它会按此顺序打印b，c，d，z。但事实并非如此。它打印了z，d，b，c。顺序没有改变。此处的原因是因为这是 prvalues 的范围，因此我们将交换的元素作为排序的一部分。好吧，他们是临时的。这对C毫无影响。

这显然行不通。用户有一个错误-他们打算按bar来对bar进行排序（即使用投影），但他们只是对bar进行排序（即使lambda返回引用，他们将对C而不是C进行 just 排序-在这种情况下，operator=中只有一个成员无论如何，但在一般情况下，这显然不是预期的行为。

但是目标实际上是：我们如何使此错误不编译？那是梦想。问题是C ++在C ++ 11中添加了引用资格，但是隐式赋值一直存在。隐式std::string("hello") = "goodbye"; // fine,but pointless,probably indicative of a bug 没有ref限定符，即使没有任何意义，您也可以分配一个右值：

operator=

仅当ravlue本身正确处理此值时，才可以分配一个右值。理想情况下，我们可以检查以确保类型具有右值限定的vector<bool>::reference。然后，代理类型（例如template <> inline constexpr bool for_real_rvalue_assignable<T> = true; ）将限定其赋值运算符，这就是我们要检查的，并且大家都很高兴。

但是我们不能这样做-因为基本上每个类型都是右值可分配的，即使实际上很少有类型有意义。因此，埃里克（Eric）和凯西（Casey）提出的在道德上等同于在类型上添加一个类型特征，即“对于合法的右值可赋值我是合法的”。与大多数类型特征不同，您会执行以下操作：

T& operator=(Whatever) const;

这只是一个拼写：

vector<int>

即使const等式运算符实际上不会作为算法的一部分被调用。它只是必须在那里。

这时您可能会问-等待，引用如何？对于“正常”范围（例如iter_reference_t<Out>，int&会给您const iter_reference_t<Out>&&，而int&仍然是views::zip。这就是为什么 。

---

此问题也是zip为什么不在C ++ 20中的原因。因为tuple<T&...>还会产生一个prvalue范围，而std::tuple正是我们在此处需要处理的代理引用类型。为了解决这个问题，我们必须对views::zip进行更改，以允许这种const可分配性。

据我所知，这仍然是它的预期方向（假设我们已经将该要求包含在一个概念中，没有标准库代理类型实际满足的要求）。因此，当添加tuple<T&...>时，vector<bool>::reference和std::ranges::sort(std::vector{false,true,true}); 都将成为常量可分配的。

这项工作的最终结果是：

pdfinfo: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory 

实际上将同时编译并正常工作。