Kolejny zbiór nowości w standardzie, z którymi nie do końca czuje się jeszcze pewnie. Myślę, że do tematu jeszcze powrócę, jak tylko stanie się on dla mnie bardziej klarowny.
Copy control
Konstruktor kopiujący
W przypadku konstruktora kopiującego
parametr jest prawie zawsze referencją na const. Rzadko zdarza się sytuacja, abyśmy byli zmuszeni do modyfikacji obiektu, z którego kopiujemy.
struct Foo {
Foo(const Foo&);
};
Zasada trzech/pięciu/zero (the rule of three/five/zero).
Istnieją trzy (pięć - w nowym standardzie) podstawowe operacje kontrolujące kopiowanie obiektu:
- konstruktor kopiujący
- operator przypisania
- destruktor
- move konstruktor
- operator przeniesienia (move)
Nie ma wymagań by tworzyć wszystkie z nich, jednak
powinny być one traktowane jako całość. Bardzo rzadko zdarza się potrzeba stosowania tylko jednej konstrukcji z pominięciem reszty. Sam Stroustrup zaleca by przy deklaracji chociaż jednej z operacji, stworzyć wszystkie pięć. W przeciwnym razie klasa nie powinna zawierać żadnej z tych konstrukcji -
"the rule of zero".
Jeżeli nie chcemy użyć któregoś z mechanizmów, poniżej wymieniono kilka zasad, którymi należy się kierować:
- Jeśli klasa wymaga destruktora, prawie na pewno wymaga konstruktora kopiującego i operatora przypisania
- Jeśli klasa wymaga konstruktora kopiującego, prawie na pewno wymaga operatora przypisania i vice versa
- Klasa która nie może być kopiowana powinna definiować konstruktor kopiujący i operator przypisania jako delete, zamiast tworzyć te dwie definicje prywatne
Tworząc operator przypisania należy pamiętać o dwóch rzeczach:
- Operator przypisania (ma to też zastosowanie dla operatora move) musi pracować poprawnie, gdy próbujemy przypisać do siebie ten same element. Ma to szczególne znaczenie jeżeli, obiekt posiada dane zapisane w pamięci dynamicznej, a w wyniku przypisania tworzymy w pamięci nowe dane i kasujemy stare. W takim przypadku dobrą praktyką jest skopiowanie wartości po prawej stronie do zmiennej lokalnej, zniszczenie wartości stojącej po lewej i w końcu przypisanie jej wartości tymczasowej. [C++Primer, s. 512; s. 536]
- Większość operatorów przypisania współpracuje z destruktorem i konstruktorem kopiującym
Storage& operator=(const Storage& r) {
auto tmp = new string(*r.data);
delete data;
data = tmp;
return *this;
}
W przeciwieństwie do mechanizmów copy-control
swap nigdy nie jest wymagany, jednakże zdefiniowanie własnej metody, może być ważną optymalizacją dla klasy, która alokuje zasoby. Operatory przypisania, które korzystają z techniki
"copy and swap", są automatycznie odporne na wyjątki i obsługują samoprzypisanie.
Należy pamiętać tylko o jednej rzeczy.
Nigdy nie wolno wołać bezpośrednio std::swap(). Wymusza to bowiem korzystanie z wersji bibliotecznej
swap(), tymczasem klasa może mieć zmienną, która posiada własną wersję tej funkcji. Najlepiej by wyboru dokonał kompilator, przez wciągnięcie przestrzeni nazw.
inline void swap(Storage &l, Storage& r) {
using std::swap;
swap(l.data, r.data);
swap(l.counter, r.counter);
}
void swap(Counter &l, Counter &r) {
Clock *tmp = l.clock;
l.clock = r.clock;
r.clock = l.clock;
}
Jeżeli klasa posiada chociaż jeden z mechanizmów tj.: konstruktor kopiujący, operator przypisania lub destruktor
kompilator nie stworzy nam konstruktora i operatora move!
Move semantic
Najtrudniejsza rzecz, jaka przyszła mi do opanowania wraz z nowym standardem, czyli move semantic. Kilka linków:
Ponieważ kompilatory mogą optymalizować tworzenie zmiennych tymczasowych (
copy elision), które służą tylko do zainicjowania innych zmiennych wyłączyłem tą opcję. (
g++ -std=c++11 -fno-elide-constructors main.cpp
std::move i std::forward
Ciekawie o nich opowiedział Scott Meyers w swoim wykładzie
An Effective C++11/14 Sampler na GoingNative 2013, z czego sporo zaczerpnąłem. Żadne z mechanizmów niczego nie obiecuje, ich zadaniem jest jedynie rzutowanie (podczas kompilacji) do rvalue:
- std::move (rzutowanie bezwarunkowe) - przekazuje obiekt jako rvalue
- std::forward (rzutowanie warunkowe) - przekazuje obiekt jako rvalue, tylko jeżeli oryginalny obiekt był rvalue inaczej będzie to lvalue
std::move nie gwarantuje tego że coś zostanie przesunięte. Np. jego działanie na obiekcie
const spowoduje jego skopiowanie. Korzystając z tego mechanizmu trzeba być bardzo ostrożnym ponieważ kompilator raczej nie poinformuje nas gdy
std::move nie będzie przesuwać ("rozświetliło" by to bibliotekę standardową).
Korzystając z
std::move obiecujemy, że nie będziemy korzystać już z danego obiektu chyba, że zamierzamy do niego coś przypisać lub go zniszczyć. Po wykonaniu
std::move nie mamy żadnej gwarancji co do wartości przesuniętego obiektu.
Głównym zadaniem
std::forward jest przekazanie argumentu (rvalue, lvalue, z
const-em lub nie) w niezmienionej formie, do innej funkcji. Jeśli oryginalny obiekt, który jest wstawiony do
std::forward był rvalue, zrobi z niego rvalue, a jeżeli lvalue, to lvalue - dlatego właśnie jest warunkowy.
void process(Storage& lvalue) {
cout << "By lvalue reference" << endl;
}
void process(Storage&& rvalue) {
cout << "By rvalue reference" << endl;
}
template <typename T>
void log(T&& param) {
process(std::forward<T>(param));
}
int main() {
Storage st;
log(st); // przekazanie jako lvalue
log<Storage>(std::move(st)); // przekazanie jako rvalue
}
Wynik:
Default constr.: defaultData
By lvalue reference
By rvalue reference
Destructor: defaultData
"Jeżeli oczekujesz szybkiego działania przekazuj przez wartość"
Zalecenia do poprzednich wersji standardu sugerowały by lvalue były opatrzone modyfikatorem
const. Jest to już nieprawdą, bowiem powodowało by to kopiowanie obiektu. Jeżeli chcemy coś przesunąć,
const nam w tym przeszkodzi.
void process(const Storage st) {
Storage my = std::move(st); // Kopiowanie!
}
int main() {
Storage st;
process(st);
}
Wynik
Default constr.: defaultData
Copy constructor: defaultData
Copy constructor: defaultData
Destructor: defaultData
Destructor: defaultData
Destructor: defaultData
noexcept dla operacji move
Ponieważ z założenia operacje "move konstruktora" i "move operatora" kradną zasoby i nie alokują żadnych nowych, więc nie powinny też rzucać żadnych wyjątków. Powinniśmy poinformować o tym kompilator stosując
noexcept. Co więcej, kontenery takie jak
std::vector, sprawdzają, czy "move konstruktor" jest
noexcept (podczas realokacji), jeżeli nie, zostanie zawołany zwykły konstruktor kopiujący.
#include <iostream>
#include <string>
#include <vector>
using namespace std;
struct Verbose {
Verbose(std::string) { cout << "Constructor" << endl; }
Verbose(const Verbose&) { cout << "Copy" << endl; }
Verbose(Verbose &&) /*noexcept*/ {
cout << "Move" << endl;
}
Verbose& operator =(const Verbose&) { cout << "assign=" << endl; }
Verbose& operator =(Verbose&&) noexcept { cout << "move=" << endl; }
~Verbose() noexcept { cout << "Destructor" << endl; }
};
int main() {
std::vector<Verbose> v;
v.emplace_back("aaa");
v.emplace_back("bbb");
}
Wynik:
Constructor
Constructor
Copy
Destructor
Destructor
Destructor
Uboczne działania destruktora
Move semantic niesie jeszcze jedno zwodnicze działanie, o którym należy pamiętać. Nigdy nie mamy pewności kiedy zostanie zawołany destruktor obiektu, z którego przenosimy zasoby.
Jeżeli zdefiniowaliśmy własny destruktor, który ma jakieś działania uboczne, należy pamiętać o odpaleniu tego samego kodu w konstruktorze i operatorze move.
Przykłady
Pora na przykład, który pokazuje różne scenariusze, z którymi mamy do czynienia kopiując bądź przesuwając obiekty. Na początku "gadatliwa" klasa, która pokazuje, który z mechanizmów copy-control został użyty.
#include <iostream>
#include <string>
#include <vector>
#include <functional>
using namespace std;
struct Storage {
Storage() : data("defaultData") {
cout << "Default constr.: " << data << endl;
}
Storage(std::string str) : data(str) {
cout << "Constructor: " << data << endl;
}
Storage(const Storage& st) : data(st.data) {
cout << "Copy constructor: " << st.data << endl;
}
Storage(Storage&& st) noexcept : data(std::move(st.data)) {
st.data = "old " + data + ", data was moved from here";
cout << "Move constructor: " << data << endl;
}
Storage& operator=(const Storage& st) {
if (&st != this) {
cout << "operator= copy: " << data << " := " << st.data << endl;
data = "old " + data + ", now assigned " + st.data;
} else {
cout << "operator= copy: " << data << " (this)" << endl;
}
return *this;
}
Storage& operator=(Storage&& st) noexcept {
if (&st != this) {
cout << "operator= move: " << data << " := " << st.data << endl;
string old_copy = data;
data = std::move(st.data);
st.data = "old " + data + ", data was moved from here";
data = "old " + old_copy + ", now assigned " + data;
} else {
cout << "operator= move: " << data << " (this)" << endl;
}
return *this;
}
~Storage() noexcept {
cout << "Destructor: " << data << endl;
}
std::string data;
};
W przykładach
simpleExample5 i simpleExample6, rzutujemy (
std::move) wartość do rvalue reference - jest to referencja, więc stare dane zostają na miejscu (nic nie jest przesuwane, ani kopiowane).
void simpleExample1() {
Storage st("val_1");
st = st;
}
void simpleExample2() {
Storage st1("val_1");
Storage st2("val_2");
st1 = st2;
}
void simpleExample3() {
Storage st1("val_1");
Storage st2("val_2");
st1 = std::move(st2);
}
void simpleExample4() {
Storage st1("val_1");
Storage st = std::move(st1);
}
void simpleExample5() {
Storage st1("val_1");
Storage&& st = std::move(st1);
}
void simpleExample6() {
Storage&& st1 = std::move(Storage("val_1"));
}
int main() {
cout << "simpleExample1():" << endl;
simpleExample1();
cout << "simpleExample2():" << endl;
simpleExample2();
cout << "simpleExample3():" << endl;
simpleExample3();
cout << "simpleExample4():" << endl;
simpleExample4();
cout << "simpleExample5():" << endl;
simpleExample5();
cout << "simpleExample6():" << endl;
simpleExample6();
}
Wynik dla
simpleExample*:
simpleExample1():
Constructor: val_1
operator= copy: val_1 (this)
Destructor: val_1
simpleExample2():
Constructor: val_1
Constructor: val_2
operator= copy: val_1 := val_2
Destructor: val_2
Destructor: old val_1, now assigned val_2
simpleExample3():
Constructor: val_1
Constructor: val_2
operator= move: val_1 := val_2
Destructor: old val_2, data was moved from here
Destructor: old val_1, now assigned val_2
simpleExample4():
Constructor: val_1
Move constructor: val_1
Destructor: val_1
Destructor: old val_1, data was moved from here
simpleExample5():
Constructor: val_1
Destructor: val_1
simpleExample6():
Constructor: val_1
Destructor: val_1
W przykładzie
returnValue1, kompilator sam się domyśli, że stworzona lokalnie (w
ret()) zmienna zaraz zostanie zniszczona, więc zamiast korzystać z operatora przypisania (jak to było dawnej) zoptymalizuje tą operację przesuwając stworzoną zmienną lokalną. Ponieważ wyłączona jest optymalizacja "copy elision", widać dwa przesunięcia. Pierwsze przesuwa lokalną zmienną do zmiennej na stosie, drugie ze zmiennej na stosie do docelowej zmiennej
st.
W drugim przypadku (
returnValue2), mamy podobną sytuację, z tą różnicą, że zamiast "move operatora" działa "move konstruktor". Gdyby "copy elision" było włączone, kompilator prawdopodobnie wyciągnąłby wywołanie z tak prostej funkcji jak
ret() i wywołał po prostu konstruktor w ciele naszego przykładu.
Storage ret() {
Storage tmp("local_val");
return tmp;
}
void returnValue1() {
Storage st("val_1");
st = ret();
}
void returnValue2() {
Storage st = ret();
}
int main() {
cout << "returnValue1():" << endl;
returnValue1();
cout << "returnValue2():" << endl;
returnValue2();
}
Wyniki dla
returnValue*:
returnValue1():
Constructor: val_1
Constructor: local_val
Move constructor: local_val
Destructor: old local_val, data was moved from here
operator= move: val_1 := local_val
Destructor: old local_val, data was moved from here
Destructor: old val_1, now assigned local_val
returnValue2():
Constructor: local_val
Move constructor: local_val
Destructor: old local_val, data was moved from here
Move constructor: local_val
Destructor: old local_val, data was moved from here
Destructor: local_val
Ostatni przykład pokazuje, że do funkcji można przekazać parametr korzystając z
std::move, a więc niejako "prosząc" o skorzystanie z mechanizmu move semantic. Gdyby parametr był oznaczony modyfikatorem
const, nie było by to możliwe.
Storage set(Storage st_set) {
return st_set;
}
void settingValue1() {
Storage st1("val_1");
Storage st = set(st1);
}
void settingValue2() {
Storage st = set(Storage("val_1"));
}
void settingValue3() {
Storage st1("val_1");
Storage st = set(std::move(st1));
}
int main() {
cout << "settingValue1():" << endl;
settingValue1();
cout << "settingValue2():" << endl;
settingValue2();
cout << "settingValue3():" << endl;
settingValue3();
}
Wyniki dla
settingValue*.
settingValue1() - "copy elision" OFF:
Constructor: val_1
Copy constructor: val_1
Move constructor: val_1
Move constructor: val_1
Destructor: old val_1, data was moved from here
Destructor: old val_1, data was moved from here
Destructor: val_1
Destructor: val_1
settingValue1() - "copy elision" ON:
Constructor: val_1
Copy constructor: val_1
Move constructor: val_1
Destructor: old val_1, data was moved from here
Destructor: val_1
Destructor: val_1
settingValue2():
Constructor: val_1
Move constructor: val_1
Move constructor: val_1
Move constructor: val_1
Destructor: old val_1, data was moved from here
Destructor: old val_1, data was moved from here
Destructor: old val_1, data was moved from here
Destructor: val_1
settingValue3():
Constructor: val_1
Move constructor: val_1
Move constructor: val_1
Move constructor: val_1
Destructor: old val_1, data was moved from here
Destructor: old val_1, data was moved from here
Destructor: val_1
Destructor: old val_1, data was moved from here
Do funkcji
pass możemy przekazać tylko rvalue reference (przez rzutowanie
std::move), wszelkie próby wsadzenia parametru lvalue (
"jeśli zmienna ma nazwę to jest lvalue") zakończą się błędem. Taki parametr najczęściej pojawia się w metodach bibliotecznych i informuje, że możemy ukraść zasoby ze zmiennej. Towarzyszy jej bliźniacza metoda (przyjmująca
const T&) będąca wersją służącą do kopiowania zasobów.
Storage pass(Storage&& st) {
return st;
}
void passingValue1() {
Storage st1("val_1");
Storage st = pass(std::move(st1));
}
int main() {
cout << "passingValue1():" << endl;
passingValue1();
}
Wynik dla
passingValue*:
passingValue1():
Constructor: val_1
Copy constructor: val_1
Move constructor: val_1
Destructor: old val_1, data was moved from here
Destructor: val_1
Destructor: val_1
Próba zdefiniowania własnego konstruktora kopiującego, operatora przypisania albo destruktora kończy się tym, że kompilator nie wygeneruje za nas operatora i konstruktora move.
struct StorageDestructor : public Storage {
~StorageDestructor() noexcept {
cout << "Own destructor: " << data << endl;
}
};
void deriveWithDestructor1() {
StorageDestructor st1;
StorageDestructor st2;
st1 = std::move(st2);
}
int main() {
cout << "deriveWithDestructor1():" << endl;
deriveWithDestructor1();
}
Wynik dla
deriveWithDestructor1:
deriveWithDestructor1():
Default constr.: defaultData
Default constr.: defaultData
operator= copy: defaultData := defaultData
Own destructor: defaultData
Destructor: defaultData
Own destructor: old defaultData, now assigned defaultData
Destructor: old defaultData, now assigned defaultData
Kolejny przykład. Choć klasa przez zdefiniowanie własnego destruktora zapobiega stworzeniu (implicit) konstruktora i operatora move, nadal mamy możliwość wymusić ich powstanie przez skorzystanie z
default.
struct StorageWithDefaultMove : public Storage {
// Destruktor zapobiega niejawnemu wygenerowaniu operatora move
~StorageWithDefaultMove() noexcept { }
// Wymuszamy wygenerowania operatora move!
StorageWithDefaultMove& operator=(StorageWithDefaultMove&&) = default;
};
void dervieWithOwnMoveAssign1() {
StorageWithDefaultMove st1;
StorageWithDefaultMove st2;
st1 = std::move(st2);
}
int main() {
cout << "dervieWithOwnMoveAssign1():" << endl;
dervieWithOwnMoveAssign1();
}
Wynik dla
dervieWithOwnMoveAssign1:
dervieWithOwnMoveAssign1():
Default constr.: defaultData
Default constr.: defaultData
operator= move: defaultData := defaultData
Destructor: old defaultData, data was moved from here
Destructor: old defaultData, now assigned defaultData
Reference qualifier
Nowe definicje i mechanizmy wstecznej kompatybilności sprawiły, że biblioteka standardowa pozwala teraz na
przypisywanie do rvalue! Czasami takie użycie może być zaskakujące. Poniższy kod jest prawidłowy.
string s1;
string s2;
s1 + s1 = "Hello world!";
Możemy się przed tym ustrzec w naszych klasach,
zmuszając by operand lewostronny (obiekt, na który wskazuje this), był lvalue. Pozwala na to reference qualifier (
& dla lvalue, oraz
&& dla rvlaue), który stosuje się tak jak
const, gdy chcemy oznaczyć metody, które nie mogą modyfikować pól obiektu.
Tak jak
const, kwalifikatory te można stosować dla funkcji nie statycznych, muszą też znajdować się w deklaracji i definicji, a jeżeli występują razem z
const zapisuje się je na końcu. Jeżeli definiujemy dwie lub więcej metod, które mają takie same nazwy i listę parametrów, musimy wprowadzić reference qualifier dla nich wszystkich, albo dla żadnej.
Przykład. Utworzona został
operator=, ale tylko dla lvalue. Dodatkowo stworzone zostały dwie metody
info, wołające różny kod w zależności od tego na jakim obiekcie zostały zawołane.
#include <iostream>
using namespace std;
class Foo {
public:
Foo operator+(const Foo &) {
return *this;
}
Foo &operator=(const Foo &) & {
return *this;
}
void info() const & {
cout << "info: lvalue" << endl;
}
void info() && {
cout << "info: rvalue" << endl;
}
};
Foo retFoo() {
return Foo();
}
int main() {
Foo f1;
Foo f2;
Foo f3;
// (f1 + f2) = f3; // Error - zapis do rvalue, ale brak takiego operatora
// retFoo() = f3; // Error - zapis do rvalue, ale brak takiego operatora
f1.info();
retFoo().info();
}
Wynik:
info: lvalue
info: rvalue
