Jaka jest zaleta korzystania z uniwersalnych referencji w pętlach opartych na zasięgu?

Question

const auto& byłoby wystarczające, jeśli chcę wykonywać operacje tylko do odczytu. Jednak ostatnio kilka razy zdarzyło mi się natrafić na

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

. Zastanawiam się:

Czy jest możliwe, że w niektórych niejasnych przypadkach narożnych występuje pewna korzyść z wydajności przy użyciu odniesień uniwersalnych, w porównaniu do auto& lub const auto&?

(shared_ptr jest podejrzany o niejasnych przypadkach narożnych)

---

Aktualizacja dwa przykłady, które znalazłem w moich ulubionych:

Any disadvantage of using const reference when iterating over basic types?
Can I easily iterate over the values of a map using a range-based for loop?

Należy skoncentrować się na pytanie: dlaczego chciałbym użyć auto & & w zakresie dla pętli?

Answer 1

Jedyną zaletą jaką widzę jest to, że iterator sekwencji zwraca referencję proxy i trzeba działać na tym odwołaniu w sposób inny niż const. Na przykład rozważyć:

#include <vector> 

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

nie skompilować, ponieważ RValue vector<bool>::reference wrócił z iterator nie będzie wiązać się z const odniesienia lwartości. Ale to zadziała:

#include <vector> 

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

Nie zakodowałem w ten sposób, chyba że wiedziałeś, że musisz zaspokoić taki przypadek. To znaczy. Nie zrobiłbym tego bezinteresownie, ponieważ powoduje, że ludzie zastanawiają się, co robisz. A gdybym zrobił to zrobić, to nie zaszkodzi to komentarz, dlaczego:

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

Edycja

Ten ostatni przypadek kopalni powinien być naprawdę szablon sensu. Jeśli wiesz, że pętla zawsze obsługuje odwołanie do proxy, wówczas auto zadziała równie dobrze jak auto&&. Ale kiedy pętla czasami obsługiwała odniesienia nie-proxy, a czasem referencje proxy, wtedy myślę, że rozwiązaniem byłoby rozwiązanie auto&&.

Answer 2

Korzystanie z lub universal references z opcją opartą na odległościach for ma tę zaletę, że rejestruje to, co dostajesz. Dla większości rodzajów iteratorów prawdopodobnie uzyskasz albo T& albo T const& dla pewnego typu T. Ciekawym przypadkiem jest to, że dereferencja z iteratorem jest tymczasowa: C++ 2011 uzyskał luźniejsze wymagania, a iteratory niekoniecznie muszą dostarczyć wartość l.Zastosowanie uniwersalnych odniesień mecze przekazywanie argument 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; 
} 

Funkcja obiektu f można traktować T&, T const& i T inaczej. Dlaczego ciało oparte na pasmach for może być inne? Oczywiście, aby rzeczywiście skorzystać z posiadania wywnioskować typ używając uniwersalnych odniesień którą musisz przekazać je odpowiednio:

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

oczywiście używając std::forward() oznacza akceptację wszelkich zwracanych wartości zostać przeniesiony z. Czy takie obiekty mają sens w kodzie nie szablonowym, którego nie znam (jeszcze?). Mogę sobie wyobrazić, że używanie uniwersalnych odniesień może dostarczyć kompilatorowi więcej informacji, aby zrobić Właściwe Prawie. W szablonowym kodzie nie podejmuje żadnej decyzji o tym, co powinno się stać z przedmiotami.

Answer 3

W praktyce zawsze używam auto&&. Po co cię ugryźć, kiedy nie musisz? Jest również krótszy do wpisania i po prostu uważam, że jest bardziej ... przezroczysty. Kiedy używasz auto&& x, to wiesz, że x jest dokładnie *it, za każdym razem.