A kompatibilitás kapcsán felmerülhet az a kérdés, hogyan lehet a leszármazott kompatibilis az ősével, hova kerülnek az adattagok a memóriában, és hogyan lehet mindig helyes a leszármazott → ős konverzió.
Ezt úgy oldja meg a fordító, hogy a leszármazott memóriaképének az elejére kerül az ős teljes tartalma, és utána következnek a leszármazott-specifikus adattagok. Így ha van egy pointerünk (vagy referenciánk), ami valami Alakzat elejére mutat, biztos lehet benne a fordító, hogy a mutatott helyen az első adattag a szin, a típusa uint32_t, a következő egy Pont, amit a kódban referenciapont-nak hívunk, stb. A leszármazott többi adattagja pedig ezek után következik.
Mi történne, ha egy Alakzat-ot érték szerint próbálnánk átadni egy függvénynek?
Mivel az érték szerint átadott paraméterek a stackre másolódnak, a fordítónak előre tudnia kell, mennyi hely kell nekik. Egy Alakzat-nál viszont nem lehet előre tudni, hogy a leszármazottai mennyi helyet foglalnak pluszban, ezért a fordító kénytelen csak egy Alakzat-nyit hagyni, és a leszármazottak többi adattagjának nem jut hely. Tehát a memóriában leszeletelődik az Alakzat-ról a leszármazott része, és csak az ősosztály adattagjai maradnak meg.
Ha egy Kor-t próbálunk Alakzat-ként érték szerint átadni, a sugar adattag tehát elveszik. Enélkül viszont a Kor virtuális függvényei sem működhetnek, hiszen azok próbálnák használni a sugar-t, ami már nincs ott! Ezért ha egy objektum leszeletelődik, a fordító nem csak az adattagjait, hanem a viselkedését is megváltoztatja: sima Alakzat-ként viselkedne tovább, virtuális függvényhívásnál az Alakzat-é hívódna!
Ez ebben a konkrét esetben egyébként nem történhetne meg, a fordító a kezünkre csapna, mert az Alakzat absztrakt. Mivel nem létezhet belőle önálló példány, nem lehet érték szerint átadni. Persze, hiszen egy önálló Alakzat-on a rajzol függvényt sem lehetne meghívni.
Mi történne, ha az Alakzat nem lenne absztrakt?
void f(Alakzat a);
Kor k1(Pont(3, 0), 2, 0x00FF00FF);
Alakzat a1 = k1; // <- !
f(k1); // <- !Ez miért fordul le, mi történik itt?
Mindkét esetben az Alakzat copy ctora hívódik: Alakzat(Alakzat const &a). mivel a kompatibilitás miatt a Kor& → Alakzat& konverzió automatikus, ezért az Alakzat copy ctora kaphat kört is. És ő alakzatot fog létrehozni, tehát csak a színt és a referenciapontot fogja lemásolni, mivel nem tudja, hogy ténylegesen milyen alakzatról van szó.
Ha egy dinamikusan foglalt objektumot az ősosztály felől törlünk, előfordulhat váratlan memóriaszivárgás. Ősosztály felőli törlés alatt ezt értjük:
Alakzat *a = new Cimke(Pont(0, 10), "Hello world!", 0xFF0000FF);
delete a;Ezt szerencsére könnyű kikerülni, de előbb nézzük meg, mi történhet ilyenkor, ez miért baj. Vegyünk fel egy új Alakzat leszármazottat, ami egy sztringet reprezentál (Cimke, label).
class Cimke : public Alakzat {
std::string felirat;
public:
// ...
};Ezután vegyünk fel egy heterogén tárolót, amibe tegyünk dinamikusan foglalt alakzatokat, majd dolgunk végeztével töröljük őket!
std::vector<Alakzat*> alakzatok;
alakzatok.push_back(new Teglalap(Pont(1, 2), 3, 4, 0xFF0000FF));
alakzatok.push_back(new Kor(Pont(3, 0), 2, 0x00FF00FF));
alakzatok.push_back(new Cimke(Pont(0, 10), "Hello world!", 0xFF0000FF));
// ...
for(int i = 0; i < alakzatok.size(); ++i)
delete alakzatok[i];Első ránézésre helyesnek tűnhet a programunk, pedig nem az. Hogyan helyezkednek el ezek az objektumok a memóriában?
Mi történik, amikor egy Alakzat*-ként ismert Cimke objektumra hívjuk a delete-et?
Ilyenkor természetesen az Alakzat destruktora hívódik, ami meghívja az adattagjai destruktorát. Arról viszont fogalma sincs, milyen adattagok vannak a leszármazottban, pedig akár ott is lehet dinamikusan foglalt terület. Például a Cimke-nek van egy std::string adattagja, aminek a belsejében biztosan van valami dinamikusan foglalt adat.
Az Alakzat destruktora tehát csak a szin és pont adattagokról tud, a felirat adattag destruktora ezért nem fog meghívódni! Jó lenne, ha Alakzat törlésénél is a leszármazottak megfelelő destruktora hívódna, ahogy Alakzat kirajzolásánál is kör vagy téglalap rajzolódik ki. Az erre való nyelvi elemet már ismerjük, ez a virtuális függvény. Tehát az ősosztály destruktorát virtuálissá kell tennünk! Ezen felül semmi dolgunk nincs vele, tehát a törzse maradhat üres.
class Alakzat {
// ...
public:
virtual void rajzol() = 0;
virtual double terulet() = 0;
virtual ~Alakzat() {} // <- !
};Felmerülhet a kérdés, hogy mégis mikor van szükség virtuális destruktorra, a Pont osztályunknál például feleslegesnek érezhetjük.
Ez a fajta memóriaszivárgás akkor lép fel, ha az ősosztály felől törlünk egy objektumot, tehát heterogén kollekcióban van. Heterogén kollekciónak viszont csak akkor van értelme, ha van virtuális függvény az ősosztályban. Tehát ökölszabályként elmondhatjuk, a destruktort akkor és csak akkor kell virtuálissá tennünk az ősben, ha van legalább egy virtuális függvénye.
A virtuális függvények kapcsán jogosan merülhet fel a kérdés, hogyan derül ki futásidőben, melyik rajzol-nak kell hívódnia. A tároló bejárásánál csak Alakzat*-okat látunk, a szin és pont adattagokból nem lehet tudni.
Logikusnak tűnik tehát, hogy az Alakzat-ban kell lennie valami futásidőben rendelkezésre álló információnak, ahonnan a fordító elő tudja varázsolni a megfelelő implementációt, ha szükséges. Első gondolatunk az lehet, hogy függvénypointereket tesz az objektumok belsejébe, ez azonban nem lenne szerencsés:
- Minden
Teglalappéldányban ugyanazokat a függvénypointereket kellene tárolni. - Ahány virtuális függvényünk van, annyi függvénypointer kellene minden példányba – jelen esetben 3 –, annyival nőne az objektumok mérete, pedig az előző pont miatt ez felesleges.
Ezért osztályonként van egy darab "függvénypointer"-tábla (vtable), ami tárolja egy típus összes virtuális függvényének implementációját. Egy az összes Alakzat-nak, egy a Teglalap-oknak, egy a Kor-öknek, stb. Az egyes példányok már erre a vtable-re mutató pointert tartalmaznak (vptr), tehát csak egyetlen pointernyivel nő a méretük. Mindezt természetesen elrejti előlünk a fordító, az ábrán szürkével jelöltük a rejtett részeket.
A fejezet elején szereplő alakzat_feldolgoz függvény paraméterként kap egy Alakzat const&-et, és azon meghív két virtuális függvényt. A paraméterként kapott alakzat típusa nem ismert fordítási időben, így a virtuális függvények hívásánál a vtable-höz kell fordulni. A terulet hívása például az alábbi módon történik:
- Az alakzat első – rejtett – adattagját meg kell keresni. Ez a vptr, ami az objektum pontos típusának vtable-ére mutat.
- A vptr-t dereferálni kell, az általa mutatott területen vannak a virtuális függvények függvénypointerei, mintha egy tömbben lennének.
- A vtable-ből ki kell venni a meghívandó függvény pointerét. Ez a
teruletfüggvény esetén mondjuk az 1. indexű függvénypointert jelenti. - Az így kapott függvénypointert meg kell hívni, ahogy C-ben is történt.
Az Alakzat és a Teglalap vtable-jében tehát ugyanolyan sorrendben kell következniük a függvénypointereknek. Mi a helyzet akkor a tisztán virtuális függvényekkel? Azoknak nincs implementációja, de akkor minek a címét lehet tenni a vtable-be?
A függvényre mutató pointer – mint minden pointer – ugyanúgy lehet NULL, mint bármelyik másik pointer. A tisztán virtuális függvényeknél ezért ilyenkor null pointer kerül a vtable-be, erre utal az =0 jelölésük.
Ez a leírás sem pontos technikailag, sőt, nem is lehet az. A C++ szabvány ugyanis azt sem köti meg, hogy a fordítók vtable segítségével implementálják a virtuális függvényhívás kihívásait.
A C++ ritka állatfaj az OO-t támogató nyelvek között amiatt, hogy támogatja a többszörös öröklést. A legtöbb nyelvben nem lehet két osztályból leszármazni, mert implementációs nehézségekkel jár; elsősorban a fordító oldaláról, de néha a programozó számára is.
Feladat: nézzük meg a Neptun néhány elképzelt osztályát! Legyen Hallgato, Oktato és Demonstrator!
Alapeset
A probléma lényege, hogy a demonstrátor egyszerre hallgató és oktató. Hallgat órát, és kaphat ösztöndíjat, de tarthat is órát, és kap fizetést (elvileg).
Ez OO modellezési szempontból azt jelenti, hogy a Demonstrator leszármazottja a Hallgato-nak és az Oktato-nak is.
class Hallgato { /* ... */ };
class Oktato { /* ... */ };
class Demonstrator : public Hallgato, public Oktato {
/* ... */
};Ezzel semmi baj nincsen, minden ugyanúgy működik, ahogy eddig. A Demonstrator memóriaképe ennek megfelelően két ősosztályt tartalmaz egymás alatt, utána jönnek a saját adattagjai:
A kompatibilitás és a cast-ok ilyenkor ugyanúgy működnek, ahogy eddig, csak a pointerkonverzió során ténylegesen megváltozhat a memóriacím is. Az ábrán az Oktato* típusú pointer máshova mutat, mint a Hallgato* vagy a Demonstrator*, hiszen így kompatibilisek. Ezt a trükköt is elrejti előlünk a fordító.
Gyémánt-öröklés
A problémák akkor kezdődnek, ha rájövünk, hogy a hallgatónak és az oktatónak vannak közös tulajdonságai és viselkedése:
- Mindkettőnek van neve, neptunkódja, számlaszáma.
- Mindkettőnek lehet pénzt utalni, oktatónak a fizetést, hallgatónak pedig az ösztöndíjat.
Ebből az következik, hogy van egy közös ősosztályuk, az Ember:
class Ember {
protected:
std::string nev;
std::string neptun;
std::string szamlaszam;
public:
void utal(int osszeg);
};
class Hallgato : public Ember { /* ... */ };
class Oktato : public Ember { /* ... */ };
class Demonstrator : public Hallgato, public Oktato {
/* ... */
};A fenti ábrán bemutatott memóriakép ekkor így módosul:
Azért hívják gyémántnak (diamond), mert az UML osztálydiagramon – ami a jegyzetben csak később fog szerepelni – rombusz alakzatban helyezkednek el.
Ezen már látszik, mi a baj: a demonstrátorban kétszer is megjelenik az Ember, egyszer a hallgatón, egyszer pedig az oktatón keresztül. Ez baj, hiszen ha a Demonstrator osztályból el akarjuk érni mondjuk a számlaszámát, akkor nem egyértelmű, melyik számlaszám adattagról van szó. Ilyenkor a Hallgato ősosztályon hívott tagfüggvények az egyik Ember objektum adattagjait használják, módosítják, az Oktato ősosztályon hívottak pedig a másikat, így inkonzisztencia is kialakulhat.
Ha ilyen probléma merül fel, az az esetek többségében tervezési hiba, és a probléma mélyebben gyökerezik, ez csak tünet. Ettől most tekintsünk el, és nézzük meg, hogyan lehet megoldani a problémát komolyabb újratervezés nélkül.
Erre nyilvánvalóan az lenne a megoldás, hogy egyetlen közös Ember objektum legyen egy Demonstrator objektumban. Ilyenkor viszont a Hallgato vagy az Oktato osztálynak is tudnia kell, hogy hozzájuk képest hol van az Ember objektum, hiszen a számukra eddig megszokott helyen nem lehetnek.
Az erre bevezetett C++ nyelvi elem a virtual öröklés. Ilyenkor – mint a virtual szó minden egyes jelentése esetében – pointeren keresztül érünk el valamit. Jelen esetben az ősosztály adattagjait a Hallgato és az Oktato osztályoknak kell egy pointeren keresztül elérniük, hiszen az lehet akárhol.
Ez kódban pedig így jelenik meg:
class Ember {
protected:
std::string nev;
std::string neptun;
std::string szamlaszam;
public:
void utal(int osszeg);
};
class Hallgato : public virtual Ember { /* ... */ };
class Oktato : public virtual Ember { /* ... */ };
class Demonstrator : public Hallgato, public Oktato {
/* ... */
};Az ilyen öröklésnek az a nehzésége programozói oldalról, hogy a virtuális ősosztály konstruktorát mindig a legalsó leszármazottnak kell meghívnia, itt a Demonstrator-nak. Logikus, hiszen a Hallgato és az Oktato magától azt sem tudja, hozzájuk képest hol lesz az ősosztályuk az objektumon belül, tehát konstruálni sem tudják maguknak.
Ha önálló Hallgato vagy Oktato példányokat hozunk létre, ugyanúgy működik minden, mint az alapesetben, csak az ősosztályt továbbra is egy pointeren keresztül érik el.
Az igazi, mélyen gyökerező probléma ebben a példában az, hogy összekevertük a típus és a szerep fogalmakat. Igazából itt egyetlen típusunk van, az Ember, és három szerepünk: Hallgato, Oktato, Demonstrator. Ezt a három szerepet azért nem lehet az emberek típusába foglalni, mert ugyanaz az ember bármelyik szerepet felveheti vagy leadhatja, márpedig egy objektum nem válthat típust.