Softwareentwicklung in C++ - ASC

9.4 Weitere wichtige technische Aspekte 231
wären statisch und nicht dynamisch gebunden. Dadurch würde Furchtbares
passieren, nämlich dass ausschließlich der Destruktor von BaseA aufgerufen
wird. Der Compiler hat ja statisch diesen Aufruf eingefügt. Was allerdings
passieren muss, damit das Programm korrekt funktioniert, ist, dass alle Destruktoren
der einzelnen Klassen in der Ableitungshierarchie korrekt aufgerufen
werden. Genau das erreicht man nur, wenn man mit dynamic Binding
arbeitet, also den Destruktor virtual deklariert. Damit wird zur Laufzeit
entschieden, welcher der “tiefste” Destruktor des vorliegenden Objekts ist
und von diesem ausgehend werden die anderen Destruktoren, die höher in
der Ableitungshierarchie liegen, korrekt aufgerufen.
Vorsicht Falle: Die schweißtreibendsten Debug Sessions, an denen schon
sehr viele Entwickler verzweifelt sind, ergeben sich bei der Suche nach völlig
unerklärlichen Effekten, die durch einen statisch gebundenen Destruktor
trotz dynamischer Verwendung von Objekten zustande kommen. Aus diesem
Grund lautet die Grundregel Nummer eins beim Entwickeln von C ++
Programmen:
Jede Klasse muss unbedingt einen virtual Destruktor besitzen!
Auch wenn dies in manchen Fällen aufgrund der Verwendung als nicht
notwendig erscheint, so ist man auf jeden Fall bei Einhalten dieser Regel
immer auf der sicheren Seite. Vor allem passiert es oft genug, dass nach Programmänderungen
Objekte polymorph verwendet werden, obwohl das zuvor
beim Grunddesign der Klasse noch gar nicht der Fall und leider auch nicht
mitgeplant war. Und genau dann kommt es garantiert zur Katastrophe. Zum
Glück warnen moderne Compiler, wenn man in einer Klasse virtual Methoden
hat, aber den Destruktor nicht virtual deklariert.
Nun zum eigentlichen Thema unseres Testprogramms: Es galt, herauszufinden,
wie die virtual Table aufgebaut (und auch wieder abgebaut) wird.
Um festzustellen, welche Implementation der dynamisch gebundenen Methode
gerade die “letzte aktive” in der virtual Table ist, wurden in die einzelnen
Konstruktoren und in die einzelnen Destruktoren Outputs eingebaut. Betrachtet
man den Output, der beim Erzeugen von test_object entsteht, so
kann man Folgendes beobachten:
• Im Konstruktor von BaseA wird dynamicallyBoundMethod aufgerufen.
Der tatsächlich ausgeführte Call ist die Implementation, die durch BaseA
gegeben ist.
• Im Konstruktor der davon abgeleiteten Klasse DerivedA erfolgt, wie man
sieht, ein Aufruf der Implementation, die durch DerivedA vorgegeben ist.
• Selbiges passiert in allen anderen Konstruktoren, die der Reihe nach bis
zum fertigen Objekt aufgerufen werden.
Was sagt uns das in Bezug auf die virtual Table? Nun, ganz einfach: Die
virtual Table wird sukzessive gemeinsam mit dem Aufruf der Konstruktoren