Question

为什么元素访问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>实际上是相同的，并且＆＃34;元素访问功能（即std::get）＆＃34;对于const与非const和lvalue与rvalue的所有组合，后者都被重载。为什么不是前者？

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

修改

致理查德克里滕的评论。我认为这偶尔会有用。

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

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

EDIT2

事实上，当我实施一些＆＃34; view＆＃34;类到容器类。似乎都需要可变视图（左值引用），不可变视图（const引用）和可移动视图（右值引用），并且我必须确定从可移动视图类的元素访问成员函数返回的内容：左值或右值引用？对我来说感觉有点奇怪，将rvalue引用返回到容器本身不公开这些接口的元素。哪一个是正确的？

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

Answer 1

向返回引用的所有内容添加ref-qualifiers没有特别的问题，但这基本上会使成员数量增加一倍，除了在std::move中包装返回之外，它们通常具有相同的实现。 / p>

class A
{
    int a;

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

标准库拒绝提供这些重载，就像拒绝提供许多volatile重载一样。在这种情况下，您只需std::move &值即可。

如果您正在编写自己的容器，则没有安全的理由来避免此类重载。它确实会增加维护负担，所以我会反对它。

STL容器的rvalue ref-qualifiers

修改

EDIT2

1 个答案: