Softwareentwicklung in C++ - ASC

366 12. Operator Overloading
werden kann. Hat man nun z.B. einen Pointer, der auf ein Objekt zeigt, das
in einem solchen Speicherblock liegt, dann zeigt nach einer Verschiebung des
Blocks dieser Pointer ins Nirvana. Welche lustigen Folgen das haben kann,
lässt sich leicht vorstellen.
Vorsicht Falle: Es wurde bereits implizit erwähnt, aber weil es derartig
gefährlich ist, möchte ich es hier noch einmal explizit anführen:
• Die Funktion malloc allokiert nur Speicher. Sie weiß nichts von Objekten
oder sonstigen C ++ Features. Es wird also bei Verwendung von malloc
niemals ein Konstruktor aufgerufen.
• Die Funktion free gibt nur Speicher frei. Auch sie weiß nichts von Objekten.
Es wird also bei Verwendung von free niemals ein Destruktor
aufgerufen.
Das Schlimmste, was man machen kann (und ich habe so etwas bereits in
mehr als einem C ++ Programm gesehen!), ist also Folgendes: Man legt ein
Objekt ordnungsgemäß mit new an. Anstatt allerdings das Objekt dann mit
delete wieder freizugeben, ruft man free mit dem Base-Pointer des Objekts
auf. Dadurch wird kein Destruktor aufgerufen und was das bedeutet, kann
man sich ausmalen!
Vorsicht Falle: Um den Blick nicht vom Wesentlichen abzulenken, habe
ich im Beispiel den return-Value von malloc nicht überprüft. Die Funktion
malloc ist allerdings gleich definiert wie in C: Wenn der Speicher ausgeht,
dann retourniert sie einen 0-Pointer! Diese Funktion weiß nichts von Exceptions
und wirft dementsprechend selbsttätig keine bad_alloc Exception, wenn
nicht mehr genug Speicher da ist.
Aus diesem Grund muss bei einer ernsthaften Implementation von new
immer der return-Value von malloc abgefragt und entsprechend reagiert werden.
Allerdings ist dies allein bei einer ernsthaften Implementation auch nicht
genug! Per Konvention darf man nicht blindlings eine bad_alloc Exception
werfen, denn es gibt da noch eine weitere Konvention in C ++, die man
zu beachten hat. Wie man nun korrekt nach Standard die Behandlung von
Speicherknappheit übernimmt, wird ausführlich in Abschnitt Verhalten bei
“Ausgehen” des Speichers diskutiert.
Der Vollständigkeit halber möchte ich an dieser Stelle auch noch erwähnen,
dass bei Inkludieren von auch noch die aus C bekannten Funktionen
memcpy, memmove, memchr, memcmp und memset zur Verfügung stehen.
Und natürlich muss ich auch hier gleich vor deren unsachgemäßen Verwendung
dringendst warnen.
Nach diesem kurzen aber notwendigen Ausflug in die Welt der Low-Level
Speicherverwaltung wird es Zeit zum eigentlichen Thema dieses Kapitels