Qual è il vantaggio di utilizzare i riferimenti di inoltro nei cicli for basati su intervallo?

const auto&sarebbe sufficiente se voglio eseguire operazioni di sola lettura. Tuttavia, mi sono imbattuto in

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

un paio di volte di recente. Questo mi fa pensare:

È possibile che in alcuni casi oscuri ci sia qualche vantaggio in termini di prestazioni nell'utilizzo di riferimenti di inoltro, rispetto a auto&o const auto&?

( shared_ptrè un sospetto per oscuri casi d'angolo)

Aggiorna due esempi che ho trovato nei miei preferiti:

Qualche svantaggio nell'usare il riferimento const durante l'iterazione sui tipi di base?
Posso iterare facilmente sui valori di una mappa utilizzando un ciclo for basato su intervallo?

Per favore, concentrati sulla domanda: perché dovrei utilizzare auto && nei cicli for basati su intervallo?

L'unico vantaggio che posso vedere è quando l'iteratore di sequenza restituisce un riferimento proxy e devi operare su quel riferimento in modo non const. Ad esempio, considera:

#include <vector>

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

Questo non viene compilato perché rvalue vector<bool>::referencerestituito da iteratornon si associa a un riferimento lvalue non const. Ma questo funzionerà:

#include <vector>

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

Detto questo, non codificherei in questo modo a meno che tu non sapessi di dover soddisfare un caso d'uso del genere. Cioè non lo farei gratuitamente perché fa sì che le persone si chiedano cosa stai facendo. E se lo facessi, non sarebbe male includere un commento sul perché:

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

modificare

Quest'ultimo mio caso dovrebbe davvero essere un modello per avere un senso. Se sai che il ciclo gestisce sempre un riferimento proxy, allora autofunzionerebbe altrettanto bene auto&&. Ma quando il ciclo a volte gestiva riferimenti non proxy e talvolta riferimenti proxy, penso che auto&&sarebbe diventata la soluzione preferita.

Utilizzando auto&&o riferimenti universali con una gamma basata for-loop ha il vantaggio che si coglie ciò che si ottiene. Per la maggior parte dei tipi di iteratori probabilmente otterrai un T&o un T const&per qualche tipo T. Il caso interessante è quello in cui la dereferenziazione di un iteratore produce un valore temporaneo: C ++ 2011 ha requisiti meno rigidi e gli iteratori non sono necessariamente tenuti a fornire un lvalue. L'uso di riferimenti universali corrisponde all'argomento forwarding in 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;
}

L'oggetto funzione fpuò trattare T&, T const&e Tdifferentemente. Perché il corpo di un forloop basato sulla gamma dovrebbe essere diverso? Naturalmente, per trarre effettivamente vantaggio dall'aver dedotto il tipo utilizzando riferimenti universali, dovresti trasmetterli in modo corrispondente:

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

Ovviamente, usare std::forward()significa accettare qualsiasi valore restituito da cui spostare. Non so (ancora?) Se oggetti come questo abbiano molto senso nel codice non modello. Posso immaginare che l'uso di riferimenti universali possa offrire più informazioni al compilatore per fare la cosa giusta. Nel codice basato su modelli rimane fuori dal prendere qualsiasi decisione su cosa dovrebbe accadere con gli oggetti.

Io praticamente uso sempre auto&&. Perché farti mordere da un caso limite quando non devi? È anche più breve da digitare e lo trovo semplicemente più ... trasparente. Quando lo usi auto&& x, allora sai che xè esattamente *it, ogni volta.