Softwareentwicklung in C++ - ASC

12.3 Speicherverwaltung 389
bedeutet, dass wir durch Overloading der globalen Operatoren ausschließlich
die Verwaltung des Speichers für Objekte übernehmen können, deren Klassen
selbst noch keine besondere Speicherverwaltung implementieren.
Vorsicht Falle: Da die globalen Operatoren nur dann herangezogen werden,
wenn eine Klasse nicht bereits selbst die entsprechenden new und delete
Operatoren implementiert, hat das Austauschen der Speicherverwaltung für
ein gesamtes Programm nach dieser Methode mit äußerster Umsicht zu geschehen.
Sonst kann es leicht zu sehr unangenehmen Interferenzen kommen,
sollten die Prinzipien der beiden Speicherverwaltungsalgorithmen nicht kompatibel
zueinander sein!
Besonders bösartig wird dieser Fehler, wenn z.B. eine Klasse, aus welchen
Gründen auch immer, nur die new Operatoren implementiert, aber delete
dem System überlässt. Dann passiert nämlich der Fall, dass das klasseninterne
new und als Gegenstück dazu das globale delete aufgerufen wird.
Plötzlich bekommt also das globale delete einen Block zur Freigabe, den
es selbst gar nicht bereitgestellt hat! Je nachdem, welcher Algorithmus für
die globale Speicherverwaltung implementiert wurde, kann dies dazu führen,
dass sich die Entwickler des Programms mit erheblichen Tiefflugversuchen
desselben konfrontiert sehen, die sie sich beim besten Willen nicht erklären
können.
Daher möchte ich hier ganz eindringlich einen Ratschlag anbringen:
Wenn man eine individuelle Speicherverwaltung für eine Klasse
schreibt, dann müssen unbedingt immer die Operatoren paarweise
implementiert werden. Niemals darf ein new ohne zugehöriges
delete implementiert werden oder umgekehrt!
Je nachdem, was man mit individueller Speicherverwaltung in Klassen
bezweckt, kann man vorausschauend genug arbeiten, um dieses Problem zumindest
in einigen Fällen gar nicht erst aufkommen zu lassen. Nehmen wir
an, die new und delete Operatoren wurden deshalb in einer Klasse individuell
implementiert, weil zusätzlich zum Beschaffen und Freigeben von Speicher
noch etwas anderes stattfinden soll (z.B. inkrementieren bzw. dekrementieren
eines Reference Counters). Wo der Speicher herkommt, ist allerdings den
Operatoren egal, sie würden sowieso einfach nur malloc und free verwenden.
Für diesen Fall kann man den zuvor erwähnten Stolperstein umgehen,
indem man nicht malloc und free aufruft, sondern stattdessen, mittels
Scope-Operator, die globalen Operatoren new und delete bzw. new[] und
delete[]. Solange diese nicht von uns besonders implementiert sind, werden
automatisch die systeminternen Operatoren herangezogen, sonst unsere
besonderen Varianten. Schreiben wir also unsere Implementation der Operatoren
für das MemoryManagedObject den neuen Erkenntnissen entsprechend
um (global_new_delete_overloading_version2.cpp):