Operator move assignment i ' if (this!= & rhs)"

Najpierw pomyliłeś podpis operatora przyporządkowania ruchu. Ponieważ moves kradnie zasoby z obiektu źródłowego, źródłem musi być odniesienie nie-const r-value reference.

Class &Class::operator=( Class &&rhs ) {
    //...
    return *this;
}

Zauważ, że nadal wracasz przez (non-const) l - odniesienie do wartości.

Dla każdego typu bezpośredniego przydziału, standardem nie jest sprawdzanie samo-przydziału, ale upewnienie się, że samo-przydział nie spowoduje awarii i spalenia. Ogólnie nikt nie robi x = x ani y = std::move(y) wywołania, ale aliasing, zwłaszcza poprzez wiele funkcji, może prowadzić a = b lub c = std::move(d) do samodzielnego przypisania. Jawna Kontrola samo-przypisania, tj. this == &rhs, która pomija mięso funkcji, gdy prawda jest jednym ze sposobów zapewnienia bezpieczeństwa samo-przypisania. Ale jest to jeden z najgorszych sposobów, ponieważ optymalizuje (miejmy nadzieję) rzadki przypadek, podczas gdy jest to anty-Optymalizacja dla bardziej powszechnego przypadku (z powodu rozgałęzień i ewentualnie braków w pamięci podręcznej).

Teraz, gdy (przynajmniej) jeden z operandów jest bezpośrednio obiekt tymczasowy, nigdy nie można mieć scenariusza samo-przypisania. Niektórzy opowiadają się za założeniem tego przypadku i optymalizują kod do tego tak bardzo, że kod staje się samobójczo głupi, gdy założenie jest błędne. Mówię, że wyrzucanie tych samych przedmiotów na użytkowników jest nieodpowiedzialne. Nie robimy tego argumentu dla copy-assignment; po co odwracać pozycję dla move-assignment?

Zróbmy przykład, zmieniony z innego respondenta:

dumb_array& dumb_array::operator=(const dumb_array& other)
{
    if (mSize != other.mSize)
    {
        delete [] mArray;
        mArray = nullptr;  // clear this...
        mSize = 0u;        // ...and this in case the next line throws
        mArray = other.mSize ? new int[other.mSize] : nullptr;
        mSize = other.mSize;
    }
    std::copy(other.mArray, other.mArray + mSize, mArray);
    return *this;
}

This copy-assignment radzi sobie z samodzielnym przypisaniem bez wyraźnej kontroli. Jeśli rozmiar źródła i miejsca docelowego jest różny, dealokacja i realokacja poprzedzają kopiowanie. W przeciwnym razie wystarczy kopiowanie. Self-assignment nie otrzymuje zoptymalizowanej ścieżki, jest wrzucany do tej samej ścieżki, co wtedy, gdy rozmiar źródła i miejsca docelowego zaczyna być równy. Kopiowanie jest technicznie niepotrzebne, gdy dwa obiekty są równoważne (w tym gdy są tym samym obiektem), ale taka jest cena, gdy nie robisz sprawdzanie równości (pod względem wartości lub adresu), ponieważ samo sprawdzanie byłoby stratą większości czasu. Zauważ, że self-assignment obiektu spowoduje serię SELF-assignmentów na poziomie elementu; Typ elementu musi być bezpieczny, aby to zrobić.

Podobnie jak w przykładzie źródłowym, to przypisanie kopii zapewnia podstawową gwarancję bezpieczeństwa WYJĄTKÓW. Jeśli chcesz mieć silną gwarancję, użyj operatora Unified-assignment z oryginalnego zapytania Copy and Swap , który obsługuje zarówno kopiowanie, jak i przenoszenie. Ale celem tego przykładu jest zmniejszenie bezpieczeństwa o jedną rangę, aby zyskać prędkość. (BTW, Zakładamy, że wartości poszczególnych elementów są niezależne; że nie ma niezmiennego ograniczenia ograniczającego niektóre wartości w porównaniu z innymi.)

Spójrzmy na przypisanie ruchu dla tego samego typu:

class dumb_array
{
    //...
    void swap(dumb_array& other) noexcept
    {
        // Just in case we add UDT members later
        using std::swap;

        // both members are built-in types -> never throw
        swap( this->mArray, other.mArray );
        swap( this->mSize, other.mSize );
    }

    dumb_array& operator=(dumb_array&& other) noexcept
    {
        this->swap( other );
        return *this;
    }
    //...
};

void  swap( dumb_array &l, dumb_array &r ) noexcept  { l.swap( r ); }

Typ wymienny, który wymaga dostosowania, powinien mieć dwuargumentową wolną funkcję o nazwie swap w tej samej przestrzeni nazw co Typ. (Przestrzeń nazw ograniczenie pozwala na zamianę niewykwalifikowanych wywołań na pracę.) Typ kontenera powinien również dodać funkcję Public swap member, aby pasowała do standardowych kontenerów. Jeśli członek swap nie jest podany, to funkcja wolna swap prawdopodobnie musi być oznaczona jako przyjaciel typu swappable. Jeśli dostosujesz ruchy do użycia swap, musisz podać swój własny kod zamiany; standardowy kod wywołuje kod ruchu typu, co skutkowałoby nieskończoną wzajemną rekurencją dla move-customized typy.

Podobnie jak destruktory, funkcje zamiany i operacje przeniesienia nie powinny być nigdy rzucane, jeśli w ogóle jest to możliwe, i prawdopodobnie oznaczone jako takie (W C++11). Standardowe typy bibliotek i procedury mają optymalizacje dla typów ruchomych, których nie można wyrzucić.

Ta pierwsza wersja Move-assignment spełnia podstawowy kontrakt. Znaczniki zasobów źródłowych są przenoszone do obiektu docelowego. Stare zasoby nie zostaną wycieknięte, ponieważ obiekt źródłowy nimi zarządza. Oraz obiekt źródłowy pozostaje w stanie użytkowym, w którym można zastosować do niego dalsze operacje, w tym przypisanie i zniszczenie.

Zauważ, że to przeniesienie-przypisanie jest automatycznie bezpieczne dla samodzielnego przypisania, ponieważ swap wywołanie jest. Jest również zdecydowanie bezpieczny dla WYJĄTKÓW. Problemem jest niepotrzebne przechowywanie zasobów. Stare zasoby dla celu docelowego nie są już koncepcyjnie potrzebne, ale tutaj nadal są wokół tylko po to, aby obiekt źródłowy mógł pozostać ważny. Jeśli planowane zniszczenie obiekt źródłowy jest daleko, marnujemy miejsce na zasoby, lub co gorsza, jeśli całkowita przestrzeń zasobów jest ograniczona i inne petycje dotyczące zasobów będą miały miejsce, zanim (nowy) obiekt źródłowy oficjalnie umrze.

Ta kwestia jest przyczyną kontrowersyjnych aktualnych porad guru dotyczących samonaprowadzania podczas przydzielania ruchu. Sposób pisania move-assignment bez przeciągania zasobów jest taki jak:

class dumb_array
{
    //...
    dumb_array& operator=(dumb_array&& other) noexcept
    {
        delete [] this->mArray;  // kill old resources
        this->mArray = other.mArray;
        this->mSize = other.mSize;
        other.mArray = nullptr;  // reset source
        other.mSize = 0u;
        return *this;
    }
    //...
};

Źródło jest resetowane do domyślnych warunków, podczas gdy stare miejsce docelowe zasoby są niszczone. W przypadku samodzielnego przypisania, Twój obecny obiekt popełnia samobójstwo. Głównym sposobem obejścia tego problemu jest otaczanie kodu akcji blokiem if(this != &other) lub wkręcanie go i pozwalanie klientom zjeść assert(this != &other) początkową linię (jeśli czujesz się dobrze).

class dumb_array
{
    //...
    dumb_array& operator=(dumb_array&& other) noexcept
    {
        dumb_array  temp{ std::move(other) };

        this->swap( temp );
        return *this;
    }
    //...
};

Gdy other i this są odrębne, other jest opróżniane przez przenieś do temp i tak pozostanie. Następnie this traci swoje stare zasoby na temp, podczas gdy zasoby pierwotnie posiadane przez other. Wtedy stare zasoby this giną, kiedy temp to zrobi.

Kiedy dochodzi do samodzielnego przypisania, opróżnianie other do temp również opróżnia this. Następnie obiekt docelowy odzyskuje swoje zasoby po wymianie temp i this. Śmierć temp twierdzi, że pusty obiekt, który powinien być praktycznie nie-op. The this/other obiekt zachowuje swoje zasoby.

Przypisanie do ruchu nie powinno być nigdy rzucane tak długo, jak budowa ruchu i zamiana są również. Koszt bezpieczeństwa podczas samodzielnego przydzielania to jeszcze kilka instrukcji w stosunku do typów niskopoziomowych, które powinny być zawalone wywołaniem dealokacji.

Jestem w obozie tych, którzy chcą operatorów bezpiecznych do samodzielnego przypisania, ale nie chcą pisać sprawdzeń do samodzielnego przypisania w implementacjach operator=. W rzeczywistości nawet nie chcę implementować operator=, chcę, aby domyślne zachowanie działało "od razu po wyjęciu z pudełka". Najlepsi członkowie specjalni to ci, którzy przychodzą za darmo.

To powiedziawszy, wymagania MoveAssignable obecne w standardzie są opisane w następujący sposób (z 17.6.3.1 wymagania argumentu szablonu [użyteczność.arg.wymagania], n3290):

Expression  Return type Return value    Post-condition
t = rv      T&          t               t is equivalent to the value of rv before the assignment

Gdzie symbole zastępcze są opisane jako: "t [jest modyfikowaną wartością lvalue typu T; "oraz" rv jest wartością rvalue typu T;". Zauważ, że są to wymagania stawiane typom używanym jako argumenty do szablonów biblioteki standardowej, ale patrząc gdzie indziej w standardzie zauważam, że każde wymaganie przy przypisywaniu ruchu jest podobne do tego.

Oznacza to, że {[5] } musi być "bezpieczny". Jeśli potrzebujesz testu tożsamości (np. this != &other), a następnie go dla niego, albo nie będzie nawet w stanie umieścić swoje przedmioty w std::vector! (Chyba że nie używasz tych członków / operacji, które wymagają MoveAssignable; ale nieważne.) Zauważ, że w poprzednim przykładzie a = std::move(a), wtedy this == &other rzeczywiście się utrzyma.

Ponieważ Twoja bieżąca funkcja operator= jest zapisywana, ponieważ stworzyłeś argument rvalue-reference const, nie ma możliwości, abyś "ukradł" wskaźniki i zmienił wartości przychodzącego odniesienia rvalue... po prostu nie można tego zmienić, można tylko czytać z niego. Dostrzegłbym problem tylko wtedy, gdybyś zaczął wywoływać delete na wskaźnikach itp. w twoim obiekcie this, tak jak w normalnej metodzie lvaue-reference operator=, ale taki rodzaj pokonuje punkt wersji rvalue ... tj. to wydaje się zbędne używanie wersji rvalue do wykonywania tych samych operacji normalnie pozostawionych metodzie const-lvalue operator=.

Teraz, jeśli zdefiniowałeś operator=, aby wziąć nie - const rvalue-reference, wtedy jedynym sposobem, w jaki mogłem zobaczyć, że wymagane jest sprawdzenie, było przekazanie obiektu this do funkcji, która celowo zwróciła referencję rvalue, a nie tymczasową.

Na przykład, załóżmy, że ktoś próbował napisać operator+ funkcję i wykorzystać mieszankę rvalue odniesienia i odniesienia lvalue w celu "zapobieżenia" tworzeniu dodatkowych tymczasowych obiektów podczas niektórych operacji dodawania stosu na obiekcie typu:

struct A; //defines operator=(A&& rhs) where it will "steal" the pointers
          //of rhs and set the original pointers of rhs to NULL

A&& operator+(A& rhs, A&& lhs)
{
    //...code

    return std::move(rhs);
}

A&& operator+(A&& rhs, A&&lhs)
{
    //...code

    return std::move(rhs);
}

int main()
{
    A a;

    a = (a + A()) + A(); //calls operator=(A&&) with reference bound to a

    //...rest of code
}

Teraz, z tego co rozumiem o odniesieniach rvalue, Robienie powyższego jest zniechęcające (tj. powinieneś po prostu zwrócić tymczasowe, a nie rvalue reference), ale jeśli ktoś nadal to robi, powinieneś sprawdzić, czy przychodzące rvalue-reference nie odwołuje się do tego samego obiektu co Wskaźnik this.

Moja odpowiedź jest wciąż taka, że przypisanie ruchu nie musi być ratowane przed samoobsługą, ale ma inne wyjaśnienie. Rozważmy std:: unique_ptr. Gdybym miał taką wdrożyć, zrobiłbym coś takiego:

unique_ptr& operator=(unique_ptr&& x) {
  delete ptr_;
  ptr_ = x.ptr_;
  x.ptr_ = nullptr;
  return *this;
}

src.erase(
  std::partition_copy(src.begin(), src.end(),
                      src.begin(),
                      std::back_inserter(even),
                      [](int num) { return num % 2; }
                      ).first,
  src.end());

To jest ok dla liczb całkowitych, ale nie wierzę, że można zrobić coś takiego z semantyką ruchu.

Podsumowując: przeniesienie przypisania do samego obiektu nie jest w porządku i trzeba na to uważać.

1. nie zgadzam się z Howardem, co jest złym pomysłem, ale i tak-myślę, że samo ruszanie się przypisanie" wyprowadzonych " obiektów powinno zadziałać, ponieważ swap(x, x) powinno zadziałać. Algorytmy uwielbiają takie rzeczy! Zawsze jest miło, gdy kącik sprawa po prostu działa. (I jeszcze nie widzę przypadku, w którym nie jest za darmo. Nie znaczy jednak, że nie istnieje).
2. tak zaimplementowano przypisywanie unique_ptrs w libc++: unique_ptr& operator=(unique_ptr&& u) noexcept { reset(u.release()); ...} Jest bezpieczny do samodzielnego przemieszczania się.
3. podstawowe wytyczne myślę, że powinno być OK, aby przypisać własny ruch.

Jest taka sytuacja ,o której mogę pomyśleć. Za to stwierdzenie: Myclass obj; std:: move (obj) = std:: move (obj)