Czy operator kopiowania powinien generalnie korzystać ze std :: swap?

Question

Czy dobrą praktyką powszechną jest zawsze wdrażanie moich operatorów przydziału przypisania przy użyciu numeru std::swap? Rozumiem, że jest to sposób na udostępnienie implementacji konstruktora kopii. Chciałbym uniknąć duplikowania samej logiki kopiowania. Więc tutaj jest to, co bym zrobił:

class Foo 
{ 
public: 
    Foo(Foo const& other) { /* assume valid implementation */ } 

    Foo& operator= (Foo other) 
    { 
     std::swap(*this, other); 
     return *this; 
    } 
}; 

Akt przejściu „inne” do preform operator przypisania skopiować konstrukcję (mamy wspólną logikę kopiowania w tym momencie). Zakładam, że zamiana spowoduje wywołanie konstrukcji przeniesienia (która ma tutaj implementację wygenerowaną przez kompilator).

Robię to praktycznie dla każdej klasy, w której implementuję budowę kopii, ponieważ konstruktor & nigdy nie ma innych implementacji.

Answer 1

Twój kod nie ma konstruktora ruchu. Twój konstruktor kopiowania blokuje automatyczne tworzenie konstruktora ruchu, a próba przeniesienia klasy zamiast go kopiuje.

W przypadku przypisania ruchu Twój operator= blokuje również jego automatyczne wdrażanie i może być używany w tym miejscu.

Końcowy wynik to an infinite recursive call of = (live code).

Jeśli zastosujesz się do zasady 0, nie potrzebujesz ani konstruktora kopiowania, konstruktora przenoszenia, przeniesienia, kopiowania ani destruktora. Jeśli napiszesz któryś z nich, powinieneś być przygotowany do napisania ich wszystkich.

Korzystanie z może być użyteczne, ale ponieważ musisz napisać swój ruch-przypisać i przenieść-konstruować, robiąc albo w terminach std::swap jest nieskończoną rekurencją czekającą na zdarzenie.

Answer 2

Jeśli Foo zawiera non-statyczne członkowie danych std::vector lub std::string lub zawiera elementy danych, które zawierają vector lub string (to nawet pośrednio), to może to być bardzo skuteczny sposób spowolnić swój kod w dół. Może to być nawet bardziej skuteczne niż wywoływanie std::sleep_for, ponieważ ta ostatnia nie marnuje mocy baterii na urządzeniach mobilnych.

Powód jest taki, że przypisanie kopii, które wywołuje przypisanie kopii vector lub string, ma szansę ponownego wykorzystania pojemności pojemnika. Podczas gdy idiom zawsze wyrzuca pojemność.

Aby uzyskać więcej informacji, zobacz mój ACCU 2014 talk, slides 43-53.

W szczególności należy zwrócić uwagę na wykres wydajności, który pokazuje wzrost szybkości wywoływania operatora przypisania kopii o numerze vector, a nie na podstawie idiomu kopiowania/wymiany z elementem danych vector.

this http://howardhinnant.github.io/accu_2014_48.pdf

W najlepszym przypadku idiom copy/wymiany to tak szybko, jak przy użyciu vector „s skopiować zadanie (jeśli pojemność nie jest wystarczająca). W najgorszym przypadku (gdy pojemność jest zawsze wystarczająca), kopiowanie/zamiana jest prawie 8-krotnie wolniejsze. Średnio kopiowanie/zamiana pociąga za sobą trafienie o prędkości 70% (dla tego testu).