Quel est l'avantage d'utiliser des références de transfert dans des boucles for basées sur des plages?

const auto&suffirait si je veux effectuer des opérations en lecture seule. Cependant, je suis tombé sur

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

quelques fois récemment. Cela me fait me demander:

Est-il possible que, dans certains cas obscurs, l'utilisation de références de transfert présente un avantage en termes de performances par rapport à auto&ou const auto&?

( shared_ptrest un suspect pour les cas de coin obscurs)

Mettre à jour Deux exemples que j'ai trouvés dans mes favoris:

Un inconvénient de l'utilisation de la référence const lors de l'itération sur les types de base?
Puis-je facilement parcourir les valeurs d'une carte à l'aide d'une boucle for basée sur une plage?

Veuillez vous concentrer sur la question: pourquoi voudrais-je utiliser les boucles auto && basées sur la plage pour les boucles?

Le seul avantage que je peux voir est lorsque l'itérateur de séquence renvoie une référence proxy et que vous devez opérer sur cette référence d'une manière non const. Par exemple, considérez:

#include <vector>

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

Cela ne compile pas car rvalue vector<bool>::referencerenvoyée par iteratorne sera pas liée à une référence lvalue non const. Mais cela fonctionnera:

#include <vector>

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

Cela étant dit, je ne coderais pas de cette façon à moins que vous ne sachiez que vous devez satisfaire un tel cas d'utilisation. C'est-à-dire que je ne ferais pas cela gratuitement parce que cela amène les gens à se demander ce que vous faites. Et si je le faisais, cela ne ferait pas de mal d'inclure un commentaire expliquant pourquoi:

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

Éditer

Ce dernier cas devrait vraiment être un modèle pour avoir du sens. Si vous savez que la boucle gère toujours une référence proxy, autocela fonctionnera aussi bien que auto&&. Mais lorsque la boucle traitait parfois des références non proxy et parfois des références proxy, je pense que auto&&cela deviendrait la solution de choix.

L'utilisation de références universellesauto&& ou avec une boucle basée sur une plage présente l'avantage de capturer ce que vous obtenez. Pour la plupart des types d'itérateurs, vous obtiendrez probablement un ou un pour un type . Le cas intéressant est celui où le déréférencement d'un itérateur produit une valeur temporaire: C ++ 2011 a des exigences assouplies et les itérateurs ne sont pas nécessairement nécessaires pour produire une lvalue. L'utilisation de références universelles correspond à la transmission d'argument dans :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;
}

L'objet de la fonction fpeut traiter T&, T const&et Tdifféremment. Pourquoi le corps d'une forboucle basée sur une plage devrait-il être différent? Bien sûr, pour profiter réellement d'avoir déduit le type à l'aide de références universelles, vous devez les transmettre en conséquence:

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

Bien sûr, utiliser std::forward()signifie que vous acceptez toutes les valeurs renvoyées à partir de. Je ne sais pas (encore?) Si des objets comme celui-ci ont beaucoup de sens dans un code non-modèle. J'imagine que l'utilisation de références universelles peut offrir plus d'informations au compilateur pour faire la bonne chose. Dans le code basé sur des modèles, il ne prend aucune décision sur ce qui devrait se passer avec les objets.

J'utilise pratiquement toujours auto&&. Pourquoi se faire mordre par un étui de bord alors que ce n'est pas nécessaire? C'est plus court à taper aussi, et je le trouve simplement plus ... transparent. Lorsque vous utilisez auto&& x, vous savez que xc'est exactement *it, à chaque fois.