Softwareentwicklung in C++ - ASC

184 9. Klassen in C++
man also einen Member, der dynamisch allokierten Speicher hält, so wird
dieser nicht automatisch freigegeben.
Es wird garantiert, dass der Destruktor aufgerufen wird, solange für das
Objekt noch vollständig Speicher reserviert ist. Das Freigeben des Speichers
erfolgt erst danach. Damit kann man auf jeden Fall innerhalb des Destruktors
gefahrlos auf alle Members des Objekts zugreifen.
Vorsicht Falle: Es wird als guter Programmierstil angesehen, jeder Klasse
auf jeden Fall einen Destruktor zu spendieren, auch wenn dieser im schlimmsten
Fall leer ist. Durch einen leeren Destruktor hat man zumindest offiziell
festgelegt, dass nichts Besonderes zu tun ist. Vergisst man z.B. das explizite
Aufräumen von dynamisch allokiertem Speicher, dann bekommt man
ein wachsendes Programm, was wiederum für einige schlaflose Nächte der
Entwickler sorgt. Wenn man sich angewöhnt, immer einen Destruktor zu
deklarieren und definieren, dann erinnert einen ein solcher bei einer späteren
Änderung des Klassencodes (z.B. Einführen einer neuen dynamischen
Variable) sofort beim Ansehen der Klassendeklaration daran, dass hier noch
etwas zu tun wäre. Somit ist die Gefahr des Vergessens auf jeden Fall etwas
geringer :-).
Nur für Leser, die diese Falle im Zuge des Nachschlagens lesen, ein kurzer
Vorgriff (alle anderen können diesen Hinweis übergehen): Wir werden
in späterer Folge noch eine besondere Eigenschaft des Destruktors kennen
lernen, nämlich, dass dieser unbedingt virtual sein muss. Auch dies ist in
jedem Fall zu beachten, denn die reine Existenz eines Destruktors garantiert
noch kein vollständig korrektes und funktionsfähiges Programm!
Der Vollständigkeit halber möchte ich hier noch erwähnen, dass man sowohl
Konstruktor als auch Destruktor nicht unbedingt public machen muss,
sondern dass man sehr wohl auch andere Access Specifiers für diese verwenden
kann. Wir werden später noch im Zuge von Beispielen mehrere sehr
sinnvolle Anwendungen dafür kennen lernen. Derzeit allerdings würde eine
Diskussion darüber den Rahmen sprengen.
9.2.2 Der Copy Konstruktor
Um die Sonderstellung des sogenannten Copy Konstruktors zu erkennen, sehen
wir uns einmal folgenden Code an: (implicit_copy_constr_demo.cpp):
1 // implicit copy constr demo . cpp − demo f o r an i m p l i c i t copy
2 // constructor
3
4 #include
5 #include ” u s e r t y p e s . h”
6
7 using std : : cout ;
8 using std : : endl ;
9
10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−