¿Cuál es la ventaja de utilizar referencias de reenvío en bucles for basados ​​en rangos?

const auto&Sería suficiente si quiero realizar operaciones de solo lectura. Sin embargo, me he encontrado

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

un par de veces recientemente. Esto me hace preguntarme:

¿Es posible que en algunos casos poco conocidos exista algún beneficio de rendimiento al usar referencias de reenvío, en comparación con auto&oconst auto& ?

( shared_ptres sospechoso de casos oscuros de esquina)

Actualización Dos ejemplos que encontré en mis favoritos:

¿Alguna desventaja de usar la referencia constante al iterar sobre tipos básicos?
¿Puedo iterar fácilmente sobre los valores de un mapa usando un bucle for basado en rango?

Concéntrese en la pregunta: ¿por qué querría usar auto && en bucles for basados ​​en rango?

La única ventaja que puedo ver es cuando el iterador de secuencia devuelve una referencia de proxy y necesita operar en esa referencia de una manera no constante. Por ejemplo, considere:

#include <vector>

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

Esto no se compila porque rvalue vector<bool>::referencedevuelto por iteratorno se vinculará a una referencia lvalue no constante. Pero esto funcionará:

#include <vector>

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

Dicho todo esto, no codificaría de esta manera a menos que supieras que necesitas satisfacer tal caso de uso. Es decir, no haría esto gratuitamente porque hace que la gente se pregunte qué estás haciendo. Y si lo hiciera, no estaría de más incluir un comentario sobre por qué:

#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;
}

Editar

Este último caso mío debería ser una plantilla para que tenga sentido. Si sabe que el bucle siempre está manejando una referencia de proxy, entonces autofuncionaría tan bien como auto&&. Pero cuando el bucle a veces manejaba referencias no proxy y, a veces, referencias proxy, entonces creo que auto&&se convertiría en la solución de elección.

El uso de referencias universalesauto&& o con un bucle basado en rango tiene la ventaja de que captura lo que obtiene. Para la mayoría de los tipos de iteradores, probablemente obtendrá una o una para algún tipo . El caso interesante es donde la desreferenciación de un iterador produce un temporal: C ++ 2011 tiene requisitos relajados y los iteradores no son necesariamente necesarios para producir un valor l. El uso de referencias universales coincide con el reenvío de argumentos en :forT&T const&Tstd::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;
}

El objeto de función fpuede tratar T&, T const&y Tde manera diferente. ¿Por qué debería forser diferente el cuerpo de un bucle basado en rango? Por supuesto, para aprovechar realmente haber deducido el tipo usando referencias universales, necesitaría transmitirlas de manera correspondiente:

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

Por supuesto, usar std::forward()significa que acepta cualquier valor devuelto desde el que se moverá. Si objetos como este tienen mucho sentido en el código que no es de plantilla, no lo sé (¿todavía?). Puedo imaginar que el uso de referencias universales puede ofrecer más información al compilador para hacer lo correcto. En el código con plantilla, se mantiene al margen de tomar decisiones sobre lo que debería suceder con los objetos.

Prácticamente siempre uso auto&&. ¿Por qué ser mordido por un caso extremo cuando no es necesario? También es más corto de escribir, y simplemente lo encuentro más ... transparente. Cuando lo usa auto&& x, entonces sabe que xes exactamente *it, siempre.