Vizsgáljuk meg az értékadó operátort is! Alapesetben abból szoktunk kiindulni, hogy az értékadó operátor a destruktorból és a másoló konstruktorból összerakható. Visszagondolva a kivételbiztossá tett másoló konstruktorra egy pillanatra, ezt írjuk:
template <typename T>
Vector<T> & Vector<T>::operator=(Vector<T> const &rhs) {
if (this != &rhs) {
/* dtor, copypaste */
delete[] data_;
/* copy ctor, copypaste */
size_ = rhs.size_;
data_ = new T[size_]; // kivétel?
try {
for (size_t i = 0; i != size_; ++i)
data_[i] = rhs.data_[i]; // kivétel?
} catch (...) {
delete[] data_;
throw;
}
}
return *this;
}Ha egy kicsit jobban megvizsgáljuk ezt, rájöhetünk, hogy ezer sebből vérzik. Először is, a new T[size_]
kifejezés miatt keletkezhet egy kivétel. Ha ott keletkezik, akkor a data_ pointer már nem kapja meg az új értéket.
Ez nagyon nagy baj, mert akkor úgy térünk vissza a függvényből, hogy a vektor objektum már az új méretet tárolja (pedig az új
objektumok még nem jöttek létre), a data_ pointere pedig érvénytelenné vált. Ha ezek után indexeljük a vektort, halott
memóriaterületre mutatunk, a destruktora pedig másodjára fogja a T-k destruktorát meghívni és memóriaterületét
felszabadítani. Vagyis ez végzetes hiba: a vektor inkonzisztens állapotba került, az adatszerkezet megsérült, a programunk pedig innentől
megjósolhatatlan működésű.
Nézzük meg a függvény második felét is! A T-k értékadó operátorai is dobhatnak kivételt. Ha ilyen történik, akkor
az adatszerkezet ugyan nem sérül, de a tárolt objektumok helytelenek lesznek. Egy részük átmásolódott, míg másik részük megmaradt
az alapértelmezett konstruktor által létrehozott értéken. Sajnos a kivételt hiába kapjuk el, ezt már nem tudjuk kijavítani. Hiába
delete[]-ljük az új tömböt (a catch-beli delete[], nem a másik)... Azzal csak még többet
ártunk, mert a vektor objektum is hibás lesz tőle.
Az értékadó operátor javítása
Látjuk azt, hogy az új objektumok létrehozása, másolása a kritikus művelet. Ez az, ami közben kivétel keletkezhet. A régi objektumok felszabadítása definíció szerint nem jelenthet problémát. A függvényt úgy tudjuk kijavítani, ha megcseréljük a sorrendet: a szokásos „lebontás, utána újbóli felépítés” sorrend helyett a „felépítés, utána lebontás” sorrendet kell inkább választanunk. Előbb túl kell esni a nehezén, a pointert és a méretet pedig a függvény végén beállítani. Amúgy is, általában jó ötlet változatlanul hagyni az objektum állapotát jelző tagváltozókat, amíg a tényleges változások meg nem történtek.
Tehát: lemásoljuk a kapott objektumot, közben elvégezve a kritikus műveleteket, és ha minden rendben volt, csak akkor frissítjük a vektor állapotát. Másképp fogalmazva, előbbre kell vennünk a másoló konstruktorból puskázott részt, és utána jöhet a destruktorból puskázott rész. Valahogy így:
template <typename T>
Vector<T> & Vector<T>::operator=(Vector<T> const &rhs) {
if (this != &rhs) {
/* előbb új állapot felépítése, kb. másoló konstruktor */
size_t newsize = rhs.size_;
T *newdata = new T[newsize];
try {
for (size_t i = 0; i != newsize; ++i)
newdata[i] = rhs.data_[i];
} catch (...) {
delete[] newdata;
throw;
}
/* utána régi állapot lebontása, destruktor */
delete[] data_;
/* végül adminisztráció */
size_ = newsize;
data_ = newdata;
}
return *this;
}Ez már így teljesen jó. Ha sikerül létrehoznia a másolatot, megtörténik az értékadás; ha nem sikerül, akkor pedig teljesen változatlan marad az objektum. Az egyetlen probléma a kódrészlettel a kódduplikáció; mindezt, amit látunk benne, már egyszer leírtuk a másoló konstruktorban és a destruktorban.
Másolás és csere
Bevethetünk itt egy trükköt. Ha létrehozunk egy vektort ebben
a függvényben lokális változóként, akkor le fog futni egy konstruktor és egy destruktor is. Ezt a vektort inicializálhatjuk
úgy, hogy az rhs-t kapja paraméterként, hogy ez pont a másoló konstruktort hívja:
template <typename T>
Vector<T> & Vector<T>::operator=(Vector<T> const &rhs) {
Vector<T> copy = rhs;
/* ... */ // sikeres másolás
}
Így a másoláshoz tartozó összes kritikus műveletet elvégeztük egyetlen egy sorban. Ha eljutottunk a jelölt részhez,
akkor addigra minden sikeresen lezajlott. Ez azt jelenti, hogy a copy nevű objektumban van egy teljes értékű
másolatunk az rhs-ről, ami pont úgy néz ki, mint ahogy az értékadás után a *this-nek is ki kell néznie.
Ez a függvény végén meg fog szűnni. A trükk lényege itt jön: a másolás után megcseréljük a
copy és a *this objektum tartalmát. Ezzel ellopjuk a copy-tól a másolatot, azokat az
adatokat, amikre szükségünk van, és belecsempésszük azokat az adatokat, amelyekre már nincs szükségünk. A régi adatok
megszüntetését így a copy destruktora fogja végezni:
template <typename T>
Vector<T> & Vector<T>::operator=(Vector<T> const &rhs) {
Vector<T> copy = rhs;
std::swap(size_, copy.size_);
std::swap(data_, copy.data_);
return *this;
} /* <- copy dtora itt fut, mert kijövünk a blokkból! */
A két csere pedig egyszerű művelet, ott már csak egy számpárt és egy pointerpárt kell kicserélni, aközben kivétel már nem keletkezhet.
Ezt az értékadó operátort egyébként még ennél is egyszerűbben szokás írni. Mivel eleve szükségünk van egy másolatra a paraméterként átvett objektumról, megtehetjük azt is, hogy rögtön másolatként vesszük azt át, tehát érték szerint:
template <typename T>
Vector<T> & Vector<T>::operator=(Vector<T> rhs) {
std::swap(size_, rhs.size_);
std::swap(data_, rhs.data_);
return *this;
}És ezzel megkaptuk a Tökéletes Értékadó Operátort. Ezt másolás és cserének nevezik (copy and swap idiom). Mint az látszik is, így egyszerűbb visszavezetni a másoló értékadást a másoló konstruktorra, mintha a másoló konstruktort próbálnánk meg az értékadásra visszavezetni. Már csak azért is, mert a konstruktort megírni sokkal egyszerűbb, annak nem kell azzal foglalkoznia, hogy az objektum régi állapotát megőrizze. Az értékadó operátorban ilyennel is kellene bajlódni, ezért az szükségképpen bonyolultabb.
Mozgatás és csere
Az értékparaméterrel rendelkező értékadó operátor érdekessége, hogy mozgató értékadásnak
is használható (move and swap idiom). Vegyük észre, ha ez az operátor egy jobbértéket kap operandusként, akkor
az rhs érték típusú paramétert nem a másoló konstruktor, hanem a move ctor fogja
inicializálni (mivel az értékparamétert mindig valamelyik konstruktor inicializálja). Ilyenkor a jobbérték
objektum erőforrásai áthelyeződnek az rhs objektumba; a cserék által pedig átkerülnek a
*this objektumba, amelynek az értéket adjuk. Végül pedig, a másoló értékadáshoz hasonlóan a
*this régi erőforrásai, mivel bekerültek az élettartamában lokális változóként viselkedő,
paraméter rhs-be, megszűnnek a visszatérés után.
Ha így írjuk meg az értékadó operátort, akkor nem kell külön másoló és mozgató értékadás függvényt írni, elég ez az egy! Az erőforrást kezelő osztály öt speciális függvénye helyett csak négyet kell megírnunk, és ezek ráadásul még jobban is működnek, mintha külön írtuk volna meg őket.
Az ilyen értékadó operátorban az önértékadást sem kell ellenőrizni. Mivel az rhs egy objektum,
nem pedig referencia, nem lehet azonos a *this objektummal. A kivételbiztos értékadó operátorok
működésükből adódóan általában automatikusan önértékadás-biztosak is, mert mindkét problémát a másolás előtti
felszabadítás okozta. Ha előbb létrehozzuk az erőforrás másolatát, és utána szabadítjuk csak fel a régit, az
önértékadásnál sincs gond. A tapasztalat egyébként azt mutatja, hogy minden olyan értékadó operátor, amelyben
önértékadásra kell vizsgálni, sántít.
Ha szokás szerint összemásolnánk a dtorból és a copy ctorból:
Vector<T> & Vector<T>::operator=(Vector<T> const &rhs) {
if (this != &rhs) {
/* dtor, copypaste */
delete[] data_;
/* copy ctor, copypaste */
size_ = rhs.size_;
data_ // kivétel => a fenti delete[] miatt érvénytelen data_
= new T[size_];
try {
for (size_t i = 0; i != size_; ++i)
data_[i] = rhs.data_[i]; // kivétel?
} catch (...) {
delete[] data_; // ugyancsak érvénytelen lesz
throw;
}
}
return *this;
} Emlékezzünk vissza a múltkori, profi memóriakezelésű vektorra! Ennek lényege az
volt, hogy különválasztottuk egymástól a dinamikus memória foglalását és az ott elhelyezkedő objektumok inicializálását. A
vektorban ezért a dinamikus memóriaterületre mutató pointer mellett kétféle méret volt eltárolva. A size_ adattag
mutatta, hogy meddig vannak a területen inicializálva az elemek, hol vannak ténylegesen objektumok, a capacity_ pedig
azt, hogy mekkora a terület teljes mérete.
template <typename T>
class MyVector {
private:
T *pData_;
size_t size_;
size_t capacity_;
};
Ennek a vektornak a kivételeket is figyelembe vevő másoló konstruktorát így tudjuk megírni:
template <typename T>
MyVector<T>::MyVector(MyVector<T> const &the_other) {
size_ = the_other.size_;
capacity_ = the_other.capacity_;
pData_ = static_cast<T*>(::operator new(sizeof(T) * capacity_)); // kivétel?
size_t i;
try {
for (i = 0; i != size_; ++i)
new (&pData_[i]) T(the_other.pData_[i]); // kivétel?
} catch (...) {
for (size_t j = 0; j != i; ++j)
pData_[j].~T();
::operator delete(pData_);
throw;
}
}Figyelem! Itt most az előző programrészek new[]-ja helyett áttértünk placement new szintaxisra!
Ez az osztály nem ugyanaz, mint az előző vektor. Ennek a destruktora is másmilyen lenne. Lent ennek a
reserve() függvényéről lesz szó, amelyik előfoglalja a helyet a később létrejövő objektumoknak – a sima
new[] operátorral nem is lehetne ilyet megvalósítani.
Vizsgáljuk meg a függvényt sorról sorra! Két helyen keletkezhet benne kivétel. Az első a foglalás (::operator
new). Ha ez nem sikerül, a beépített függvény std::bad_alloc típusú kivételt dob, amit szándékosan nem
kapunk el, hogy a hívó lássa, a vektor létrehozása nem sikerült. A másik hely pedig a T-k másoló konstruktorának
hívása. Erről nem tudunk semmit, vagy dobhat valamit, vagy nem, de mivel erőforrást kezelünk, fel kell készülnünk rá. Ha dob,
akkor a foglalt memóriát fel kell szabadítani kézzel, mert a MyVector még nem jött létre, és a destruktora ezért
nem fut automatikusan.
Ami fontos, hogy ezen kívül még a kézzel létrehozott T-ket is fel kell szabadítani. Mivel
azok az objektumok „placement new” operátorral lettek lefoglalva, a destruktorok hívásáért is mi felelünk. Ha az
i-edik indexű T másoló konstruktora hibát dobott, akkor a 0...i-1 indexen lévő elemek már
létrejöttek, ezért azoknak a destruktorát meg kell hívni a memóriaterület felszabadítása előtt. Ha mindez megtörtént, akkor
jutottunk el oda, hogy továbbdobhatjuk az ismeretlen típusú hibát. (Mindez megoldható lenne konstruktor delegálással is,
de így jobban látszik, hogy mi történik.)
Egy másik tagfüggvény, a reserve() feladata az volt, hogy átméretezze a dinamikus tömböt, megtartva az
objektumokat. Amióta ismerjük a mozgató konstruktorokat, ezt valahogy így írhatnánk
(egyelőre kivételekre nem gondolva):
template <typename T>
void MyVector<T>::reserve(size_t newcap) {
if (newcap < size_)
return;
T *newPData = static_cast<T*>(::operator new(sizeof(T) * newcap)); // ?
for (size_t i = 0; i != size_; ++i) {
new (&newPData[i]) T(std::move(pData_[i])); // ?
pData_[i].~T();
}
::operator delete(pData_);
capacity_ = newcap;
pData_ = newPData;
}Nézzük meg, itt mi történik egy kivétel keletkezésekor! Az új memóriaterület foglalása dobhat egy hibát. Ezt nem kapjuk el, jelezve a hívónak, hogy nincs hely; a hívó talán azért próbálja meg előfoglalni a helyet az objektumoknak, hogy később már ne keletkezzen hiba.
Ha az új memóriaterület megvan, akkor elkezdhetjük áthelyezni az objektumokat. A múltkori előadáson bemutatott másoláshoz képest egy okosabb dolgot tudunk itt csinálni: mivel nem másolatot szeretnénk a
T-kről, hanem áthelyezni szeretnénk őket az új memóriaterületre, a mozgató konstruktort használjuk. Ehhez az
std::move függvénnyel jobbértéknek tekintjük a balérték tömbelemeket. Tudjuk azt is, hogy az objektum, amiből
mozgattunk, még élőnek számít, ezért a destruktorát még meg kell hívni.
A lenti ábra egy köztes állapotot mutat, amikor az objektumok egy része már áthelyeződött az új tömbbe, a másik részük pedig még mindig a régi helyen tárolódik. Kérdés: mi történik akkor, ha a mozgató konstruktor kivételt dob? Bár annak triviális a feladata, mégis dobhat kivételt.
Ha ilyen történne, akkor nagyon nagy bajban lennénk. Miért is? Mert a régi helyről már elmozdítottuk az objektumokat. A mozgatás
destruktív művelet, módosítja az objektumot, amiből mozgatunk. Ha a ciklusban kivételt kapunk, akkor tudjuk, hogy a
reserve() művelet nem sikerült, és ezért – ha erős garanciát szeretnénk adni a hívónak – vissza kellene alakítanunk a
vektort az eredeti állapotába. Ez azt jelenti, hogy a már elmozdított objektumokat vissza kellene raknunk az eredeti helyükre,
mindent visszaalakítva a régi állapotba (rollback). De ezt azzal a mozgató konstruktorral kellene megtennünk, amelyről épp most
derült ki, hogy nem mindig sikeres... Így a visszahelyezgetés közben akár újabb kivételt kaphatnánk. Innentől pedig menthetetlen a
helyzet.
A problémát a destruktív művelet elkerülésével tudjuk megoldani: nem mozgatunk, hanem másolunk. Ezt azonban nem szeretnénk,
mert lassabb. Szerencsére nem kell lemondanunk a hatékonyságról, mert nem kell feltétlenül a másoláshoz ragaszkodnunk. Ha a
mozgató konstruktorról tudjuk, hogy nem dobhat kivételt, akkor akár mozgathatjuk is az objektumokat, mert akkor nem lehet ilyen probléma. Ha
viszont dobhat kivételt, csak akkor kell megelégednünk a másolással. Itt jön a képbe a noexcept operátor, amellyel le
tudjuk kérdezni a fordítótól, hogy dobhat-e kivételt a mozgatás. Lényegében erről van szó:
if (noexcept( T(std::move(pData_[i])) )) /* biztonságos ez a művelet? */
new (&newPData[i]) T(std::move(pData_[i])); /* ha igen, mozgatunk :) */
else
new (&newPData[i]) T(pData_[i]); /* ha dobhat, másolunk :( */Mindezt sokkal egyszerűbben leírhatjuk az std::move_if_noexcept() függvénysablonnal
(#include <utility>). Ez a függvénysablon a paraméterét az std::move-hoz hasonlóan jobbérték
referenciává konvertálja, de csak akkor, ha a mozgató konstruktora noexcept minősítővel rendelkezik.
Amúgy a visszatérési értéke balérték marad. Ha ennek az értékét kapja a T konstruktora, akkor
noexcept-es mozgatás esetén a mozgató konstruktor, nem noexcept-es mozgatás esetén a balérték
paraméter miatt a másoló konstruktor fog hívódni:
new (&newPData[i]) T(std::move_if_noexcept(pData_[i]));Így pedig tudni fogjuk, hogy ha kivételt kaptunk, az eredeti objektumokat nem mozgattuk el a helyükről, hanem csak lemásoltuk őket – tehát nincs más dolgunk, mint megszüntetni a másolatokat, mert az eredeti objektumok változatlanok.
template <typename T>
void MyVector<T>::reserve(size_t newcap) {
if (newcap < size_)
return;
T *newPData = static_cast<T*>(::operator new(sizeof(T) * newcap)); // 1
size_t i;
try {
for (i = 0; i != size_; ++i)
new (&newPData[i]) T(std::move_if_noexcept(pData_[i])); // 2
} catch (...) {
for (size_t j = 0; j != i; ++j)
newPData[j].~T();
::operator delete(newPData);
throw;
}
for (i = 0; i != size_; ++i)
pData_[i].~T();
::operator delete(pData_);
capacity_ = newcap;
pData_ = newPData;
}A ciklusok kicsit sokan lettek, de az STL tartalmaz ilyesmi algoritmusokat is.
Pl. az std::uninitialized_copy a placement new szintaxissal másolja az elemeket, hasonlóan a
2-essel jelzett sorhoz. A függvény a jelenlegi formájában is megírható lenne egyszerűbben,
de most nem az egyszerűség volt a cél, hanem hogy látszódjon, hogy alakult ki.
A kétféle kivételt az alábbiak szerint kezeljük. Ha az új terület foglalása dobott, azt a kivételt hagyjuk továbbmenni a
hívónak. Ha pedig a másoló konstruktorok dobnak, akkor az új tömböt felszabadítjuk – és a problémát szintén jelezzük a hívónak, a
kivétel továbbdobása által. Az új tömböt felszabadíthatjuk, mert biztos, hogy másolatok voltak benne. Ezek nem lehetnek mozgatott
objektumok, mert ahhoz a mozgató konstruktornak kellett volna futnia a 2-essel jelzett sorban, aminek noexcept
minősítővel kellett volna rendelkeznie.
Mit tanulhatunk ebből? Azt, hogy a mozgató konstruktoroknak lehetőleg nem kellene kivételt dobniuk, és ha nem dobnak, akkor
meg kell kapniuk a noexcept minősítőt is. Különben előfordulhatnak olyan körülmények, ahol nem használhatóak, hanem
helyettük a sokkal lassabb másoló konstruktort kell hívni.
Amíg a mozgató konstruktor csak a régi és az új objektummal dolgozik, addig nem is szokott nehéz lenni a noexcept
megvalósítás. Vegyünk példának egy sztring osztályt, amelyben az üres sztringet is tároljuk, hogy sose lehessen null pointerünk.
Tudjuk, hogy egy elmozgatott objektummal semmit nem szabad csinálni, csak megszüntetni vagy új értéket adni neki (azaz csak a
destruktora vagy az értékadó operátora futhat). Pontosan ezért jó ötlet null pointert hagyni benne:
class String {
public:
String() {
data_ = new char[1];
strcpy(data_, "");
}
String(String && the_other) noexcept { // nem dob kivételt
data_ = the_other.data_;
the_other.data_ = nullptr;
}
char const* c_str() noexcept { // nullptr-t adhat... vagy mégsem?
return data_;
}
private:
char *data_;
};Így ennek az osztálynak adhat a c_str() függvénye null pointert – de ha elmozgatott objektumra hívjuk
ezt a függvényt, az amúgy is hibának számít. Tehát ebben az esetben ez nem az osztály, hanem a hívó hibája lenne.
Térjünk vissza a korábbi vektor osztályunkhoz:
template <typename T>
class MyVector {
private:
T *pData_;
size_t size_;
size_t capacity_;
};