如何解决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
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。