Rule-of-Three staje się Rule-of-Five z C++11?

Nie mogę uwierzyć, że nikt nie połączył się z tym .

Zasadniczo artykuł argumentuje za "zasadą zera". Nie wypada mi cytować całego artykułu, ale uważam, że jest to główny punkt:

Klasy, które mają własne destruktory, konstruktory kopiowania / przenoszenia lub operatory przypisywania kopiowania / przenoszenia powinny zajmować się wyłącznie własnością. Inne klasy nie powinny mieć własnych destruktorów, Kopiuj/przenoś konstruktory lub operatory przypisania kopiowania/przenoszenia.

Także ten bit jest IMHO ważny:

Wspólne klasy "ownership-in-a-package" są zawarte w standardzie biblioteka: std::unique_ptr i std::shared_ptr. Poprzez zastosowanie niestandardowe obiekty deleter, oba zostały wystarczająco elastyczne, aby zarządzać praktycznie każdego rodzaju zasobów.

Nie sądzę, reguła trzech jest regułą, która mówi, że klasa, która implementuje jedną z poniższych, ale nie wszystkie, jest prawdopodobnie błędna.

1. Konstruktor kopiujący
2. operator przypisania
3. Destructor

Jednak pominięcie konstruktora move lub operatora przypisania move nie oznacza błędu. To Może być straconą szansą na optymalizację (w większości przypadków) lub że semantyka move nie jest istotna dla tej klasy, ale to nie jest pluskwa.

Chociaż najlepszym rozwiązaniem może być zdefiniowanie konstruktora ruchu, gdy jest to istotne, nie jest to obowiązkowe. std::complex) i wszystkie klasy, które zachowują się poprawnie w C++03, będą zachowywać się poprawnie w C++0x, nawet jeśli nie zdefiniują konstruktora ruchu.

Tak, myślę, że byłoby miło dostarczyć konstruktor move dla takich klas, ale pamiętaj, że:

• To tylko optymalizacja.

  Zaimplementowanie tylko jednego lub dwóch konstruktorów kopiujących, operatora przypisania lub destruktora prawdopodobnie doprowadzi do błędów, podczas gdy brak konstruktora move potencjalnie zmniejszy wydajność.

• Konstruktor Move nie zawsze może być zastosowany bez modyfikacji.

  Niektóre klasy zawsze mają swoje wskaźniki przydzielone, a stąd takie klasy zawsze kasują swoje wskaźniki w destruktorze. W takich przypadkach musisz dodać dodatkowe kontrole, aby stwierdzić, czy ich wskaźniki są przydzielone lub zostały przeniesione (są teraz null).

Oto krótka aktualizacja na temat obecnego stanu i związanych z nim wydarzeń od 24 stycznia '11.

Zgodnie ze standardem C++11 (patrz załącznik D [depr.impldec]):

Domyślna deklaracja konstruktora kopiującego jest przestarzała, jeśli klasa ma zadeklarowany przez użytkownika operator przypisania kopii lub zadeklarowany przez użytkownika Destruktor. Domyślna deklaracja operatora przypisania kopii jest przestarzała, jeśli klasa ma zadeklarowany przez użytkownika Konstruktor kopiujący lub zadeklarowany przez użytkownika Destruktor.

W rzeczywistości zaproponowano przestarzałe przestarzałe zachowanie nadające C++14 prawdziwą "regułę pięciu" zamiast tradycyjnej "reguły trzech". W 2013 roku EWG głosowała przeciwko tej propozycji, która ma zostać wdrożona w C++2014. Główne uzasadnienie decyzji w sprawie wniosku miało związek z ogólnymi obawami dotyczącymi złamania istniejącego Kodeksu.

Ostatnio zaproponowano ponowne dostosowanie sformułowania C++11 tak, aby osiągnąć nieformalny Reguła pięciu, mianowicie że

Kompilator nie może generować funkcji kopiowania, przesuwania ani destruktora, jeśli którakolwiek z tych funkcji jest dostarczana przez użytkownika.

Jeśli zostanie zatwierdzona przez EWG," reguła " prawdopodobnie zostanie przyjęta dla C++17.

Zasadniczo wygląda to tak: jeśli nie zadeklarujesz żadnych operacji przeniesienia, powinieneś przestrzegać zasady trzech. Jeśli zadeklarujesz operację move, nie ma nic złego w "naruszeniu" zasady trzech, ponieważ generowanie operacji generowanych przez kompilator stało się bardzo restrykcyjne. Nawet jeśli nie zadeklarujesz operacji przeniesienia i nie złamiesz zasady three, kompilator C++0x powinien dać Ci ostrzeżenie w przypadku, gdy jedna specjalna funkcja została zadeklarowana przez użytkownika, a inne specjalne funkcje zostały automatyczne generowanie ze względu na przestarzałą "regułę zgodności C++03".

Myślę, że można śmiało powiedzieć, że ta zasada staje się trochę mniej znacząca. Prawdziwy problem w C++03 polega na tym, że implementacja różnych semantyki kopii wymaga deklaracji wszystkich powiązanych funkcji specjalnych, tak aby żadna z nich nie była generowana przez kompilator (co w przeciwnym razie zrobiłoby coś złego). Ale C++0x zmienia zasady dotyczące generowania funkcji specjalnych. Jeśli użytkownik zadeklaruje tylko jedną z tych funkcje zmiana semantyki kopiowania uniemożliwi kompilatorowi automatyczne generowanie pozostałych funkcji specjalnych. Jest to dobre, ponieważ brakująca deklaracja zamienia błąd runtime w błąd kompilacji (lub przynajmniej Ostrzeżenie). Jako miara zgodności C++03 niektóre operacje są nadal generowane, ale ta generacja jest uważana za przestarzałą i powinna przynajmniej generować ostrzeżenie w trybie C++0x.

Ze względu na dość restrykcyjne zasady dotyczące generowanych przez kompilator funkcji specjalnych i zgodność Z C++03, reguła trzech pozostaje regułą trzech.

Oto kilka exapli, które powinny pasować do najnowszych reguł C++0x:

template<class T>
class unique_ptr
{
   T* ptr;
public:
   explicit unique_ptr(T* p=0) : ptr(p) {}
   ~unique_ptr();
   unique_ptr(unique_ptr&&);
   unique_ptr& operator=(unique_ptr&&);
};

W powyższym przykładzie nie ma potrzeby deklarowania innych funkcji specjalnych jako usuniętych. Po prostu nie będą generowane ze względu na restrykcyjne zasady. Obecność zadeklarowanych przez użytkownika operacji przeniesienia wyłącza generowane przez kompilator operacje kopiowania. Ale w takim przypadku:

template<class T>
class scoped_ptr
{
   T* ptr;
public:
   explicit scoped_ptr(T* p=0) : ptr(p) {}
   ~scoped_ptr();
};

Kompilator C++0x ma teraz generuje ostrzeżenie o możliwych operacjach kopiowania generowanych przez kompilator, które mogą zrobić złą rzecz. Tutaj zasada trzech spraw i powinny być przestrzegane. Ostrzeżenie w tym przypadku jest całkowicie odpowiednie i daje użytkownikowi szansę na poradzenie sobie z błędem. Możemy pozbyć się problemu za pomocą usuniętych funkcji:

template<class T>
class scoped_ptr
{
   T* ptr;
public:
   explicit scoped_ptr(T* p=0) : ptr(p) {}
   ~scoped_ptr();
   scoped_ptr(scoped_ptr const&) = delete;
   scoped_ptr& operator=(scoped_ptr const&) = delete;
};

Zasada trzech nadal obowiązuje tutaj tylko ze względu na kompatybilność z C++03.

Nie możemy powiedzieć, że reguła 3 staje się regułą 4 (lub 5) bez łamania całego istniejącego kodu, który wymusza regułę 3 i nie implementuje żadnej formy semantyki ruchu.

Zasada 3 oznacza, że jeśli zaimplementujesz jedną, musisz zaimplementować wszystkie 3.

Również nie są świadomi, że pojawi się jakiś automatycznie wygenerowany ruch. Celem" reguły 3 " jest to, że automatycznie istnieją i jeśli zaimplementujesz jedną, najprawdopodobniej Domyślna implementacja dwóch pozostałych jest błędna.

W ogólnym przypadku, to tak, zasada trzech stała się po prostu piątką, z operatorem przypisania ruchu i konstruktorem ruchu dodanym. Jednak nie wszystkie klasy są kopiowalne i ruchome, niektóre są po prostu ruchome, niektóre są po prostu kopiowalne.