c – STL容器的rvalue ref-qualifiers

2023年10月31日 198次阅读

为什么元素访问STL容器的成员函数,例如std :: array :: operator []或std :: vector :: operator []没有rvalue ref-qualifier重载？当然我可以做std :: move(generate_vector()[10]),但我很好奇是否在标准化ref-qualifiers时考虑添加rvalue ref-qualifier重载.

我认为std :: array< T,N>和std :: tuple< T,T,…,T>实际上是相同的,并且后者的“元素访问函数(即std :: get)”对于const与非const和lvalue与rvalue的所有组合都被重载.为什么不是前者？

将rvalue ref限定的元素访问成员函数(返回rvalue引用)添加到我的自定义容器中是一个好主意吗？

编辑

致Richard Critten的评论.我认为这偶尔会有用.

例如,您有一个函数返回在该函数内构造的容器,但您可能只对该容器的第一个元素感兴趣.是的,那太傻了.在这种情况下,使用仅构造第一个元素的简单函数肯定会更好.但如果功能不是你的,你没有这样的选择.

或者,可能有更一般的例子.您有一个构造容器的函数,并且您希望处理该容器以获得另一个结果.
例如,您可能希望对该容器执行std :: reduce或std :: unique_copy. (似乎在执行std :: reduce期间阻止修改元素,但是让我们假设我们已经实现了我们自己的允许修改.)在这种情况下,可以使用std :: make_move_iterator,但为什么不让容器本身返回移动迭代器？

EDIT2

事实上,当我向容器类实现一些“视图”类时,我遇到了这个问题.似乎都需要可变视图(左值引用),不可变视图(const引用)和可移动视图(右值引用),并且我必须确定从可移动视图类的元素访问成员函数返回的内容：左值或右值引用？对我来说感觉有点奇怪,将rvalue引用返回到容器本身不公开这些接口的元素.哪一个是正确的？

>左值参考.
>右值参考.
>一般来说,可移动的视图是不对的.经常不需要这样的东西,我的设计应该有一些严重的问题.

最佳答案 将ref-qualifiers添加到返回引用的所有内容中没有特别的问题,但是这基本上会使成员数量增加一倍,除了在std :: move中包装返回之外,它们通常具有相同的实现.

class A
{
    int a;

    int& operator[](std::size_t pos) & { return a; }
    int&& operator[](std::size_t pos) && { return std::move(a); }
};

标准库拒绝提供这些重载,就像它拒绝提供许多易失性重载一样.在这种情况下,你可以只是std :: move the&价值,你需要它.

如果您正在编写自己的容器,那么就没有安全的理由来避免这种过载.它确实增加了维护负担,所以我建议不要这样做.

点赞