c++ - STL 容器的右值引用限定符

Question

为什么元素访问STL容器的成员函数，例如std::array::operator[]或 std::vector::operator[]没有右值引用限定符重载？我当然可以做到std::move(generate_vector()[10]) ，但我很好奇在标准化引用限定符时是否考虑添加右值引用限定符重载。

我认为std::array<T, N>和 std::tuple<T, T, ..., T>实际上是同一件事，后者的“元素访问函数(即 std::get )”对于 const 与非 const 以及左值与右值的所有组合都重载了。为什么不是前者？

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

编辑

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

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

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

编辑2

事实上，我在为容器类实现一些“ View ”类时遇到了这个问题。可变 View (左值引用)、不可变 View (常量引用)和可移动 View (右值引用)似乎都是必需的，我必须确定从可移动 View 类的元素访问成员函数返回什么:左值或右值引用？我觉得有点奇怪，返回对容器本身不公开此类接口(interface)的元素的右值引用。哪一个是正确的？

1. 左值引用。
2. 右值引用。
3. 总的来说，移动 View 是不正确的。这种东西不应该经常需要，我的设计应该有一些严重的问题。

Answer 1

向返回引用的所有内容添加引用限定符并没有什么特别的问题，但是这基本上使成员数量加倍，除了将返回包装在 std::move< 之外，它们通常具有相同的实现.

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 & 值。

如果您正在编写自己的容器，则没有安全的理由来避免此类重载。它确实增加了维护负担，所以我建议不要这样做。