В чем преимущество использования ссылок пересылки в циклах for на основе диапазона?

const auto&было бы достаточно, если я хочу выполнять операции только для чтения. Однако я наткнулся на

for (auto&& e : v)  // v is non-const

пару раз за последнее время. Это заставляет меня задуматься:

Возможно ли, что в некоторых непонятных угловых случаях есть некоторое преимущество в производительности при использовании ссылок пересылки по сравнению с auto&или const auto&?

( shared_ptrподозревается в неясных делах)

Обновление Два примера, которые я нашел в своих избранных:

Есть ли недостаток использования константной ссылки при итерации по базовым типам?
Могу ли я легко перебирать значения карты, используя цикл for на основе диапазона?

Пожалуйста, сконцентрируйтесь на вопросе: зачем мне использовать auto && в циклах на основе диапазона?

Единственное преимущество, которое я вижу, - это когда итератор последовательности возвращает ссылку на прокси, и вам нужно работать с этой ссылкой неконстантным способом. Например, рассмотрим:

#include <vector>

int main()
{
    std::vector<bool> v(10);
    for (auto& e : v)
        e = true;
}

Это не компилируется, потому что rvalue, vector<bool>::referenceвозвращаемое из iterator, не будет привязываться к неконстантной ссылке lvalue. Но это сработает:

#include <vector>

int main()
{
    std::vector<bool> v(10);
    for (auto&& e : v)
        e = true;
}

При этом я бы не стал кодировать таким образом, если бы вы не знали, что вам нужно удовлетворить такой вариант использования. То есть я бы не стал делать это бесплатно, потому что это заставляет людей задуматься, чем вы занимаетесь . И если бы я это сделал, не помешало бы добавить комментарий, почему:

#include <vector>

int main()
{
    std::vector<bool> v(10);
    // using auto&& so that I can handle the rvalue reference
    //   returned for the vector<bool> case
    for (auto&& e : v)
        e = true;
}

редактировать

Этот последний мой случай действительно должен быть шаблоном, чтобы иметь смысл. Если вы знаете, что цикл всегда обрабатывает ссылку на прокси-сервер, то он autoбудет работать так же хорошо, как auto&&. Но когда цикл иногда обрабатывал непрокси-ссылки, а иногда и прокси-ссылки, я думаю, auto&&это стало бы предпочтительным решением.

Использование auto&&или универсальные ссылки с диапазоном на основе for-loop имеет то преимущество , что вы улавливает то , что вы получите. Для большинства типов итераторов вы, вероятно, получите либо a, T&либо a T const&для некоторого типа T. Интересен случай, когда разыменование итератора приводит к временному результату: C ++ 2011 имеет ослабленные требования, и итераторы не обязательно требуются для получения lvalue. Использование универсальных ссылок соответствует пересылке аргументов в std::for_each():

template <typename InIt, typename F>
F std::for_each(InIt it, InIt end, F f) {
    for (; it != end; ++it) {
        f(*it); // <---------------------- here
    }
    return f;
}

Объект функции fможет лечить T&, T const&и по- Tдругому. Почему тело цикла на основе forдиапазона должно отличаться? Конечно, чтобы на самом деле воспользоваться выводом типа с помощью универсальных ссылок, вам нужно будет передать их соответственно:

for (auto&& x: range) {
    f(std::forward<decltype(x)>(x));
}

Конечно, использование std::forward()означает, что вы принимаете любые возвращаемые значения для перемещения. Имеют ли такие объекты смысл в коде, отличном от шаблона, я не знаю (пока?). Я могу себе представить, что использование универсальных ссылок может дать компилятору больше информации, чтобы сделать правильный выбор. В шаблонном коде он не принимает никакого решения о том, что должно происходить с объектами.

Практически всегда пользуюсь auto&&. Зачем вас укусил крайний случай, когда в этом нет необходимости? Он тоже короче, и я просто считаю его более ... прозрачным. Когда вы используете auto&& x, то знаете, что xэто точно *it, каждый раз.