Softwareentwicklung in C++ - ASC

12.3 Speicherverwaltung 363
er dort keine passende Umwandlung findet, endet der Versuch der Übersetzung
des obigen Statements in einem Fehler. Es gibt auch zwei sehr gute
Gründe für dieses Verhalten:
1. Würde der Compiler Umwandlungsketten suchen (und finden), so kann
es leicht zu bösen Überraschungen bezüglich Ambiguitäten oder auch
bezüglich Verträglichkeit von Datentypen kommen, die sich eigentlich
beabsichtigterweise nicht vertragen sollten.
2. Müsste der Compiler auf die Suche nach Umwandlungsketten gehen,
dann würde ihn dies nicht wirklich performanter machen, denn dafür
wäre die Implementation von einigen sehr komplexen graphentheoretischen
Algorithmen notwendig. Und die durch Umwandlungen aufgespannten
Graphen können groß werden...
12.3 Speicherverwaltung
Waren schon selbstdefinierte Typumwandlungs-Operatoren mit Vorsicht anzuwenden,
so kommen wir jetzt zu einem Thema, das wirklich als for Experts
only ausgewiesen werden muss: Overloading der new und delete
Operatoren, um gewisse Teile der Speicherverwaltung selbst in die Hand zu
nehmen. Im Prinzip kann man damit sehr sinnvolle Konstrukte implementieren,
aber die Möglichkeiten, ungeahnte Zeitbomben in die eigene Software
einzubauen, sind auch nicht zu verachten! Man muss wirklich ganz genau wissen,
was man tut, wenn man ein Overloading von new und delete sinnvoll
und robust einsetzen will!
Genug gewarnt – wenden wir uns also nun wirklich den Grundprinzipien
einer selbstgebastelten Speicherverwaltung zu.
12.3.1 Einfaches new und delete
Bisher haben wir damit gelebt, dass bei einem Aufruf von new einfach hinter
den Kulissen genügend Speicher reserviert wurde und wir keinen Einfluss darauf
hatten, wo dieser Speicherblock hergenommen wird und wo er endgültig
zu liegen kommt. In den allermeisten Fällen ist das auch vollkommen ausreichend.
Stellen wir uns aber nun z.B. vor, dass wir es mit einem System zu tun
hätten, in dem gewisse Objekte in einem besonderen Speicherbereich liegen
müssen, um eine saubere Funktionalität zu gewährleisten. In embedded Systems
kann es schon einmal vorkommen, dass man es mit zwei verschiedenen
Arten von Speichern zu tun hat. Die eine Art von Speicher gestattet einen
schnellen Zugriff, ist aber flüchtig. Die andere Art von Speicher ist langsam,
dafür aber nicht flüchtig und gestattet daher das Speichern von Objekten, die
auch nach dem “Ausschalten” des Systems erhalten bleiben. Es ginge jetzt