Ein Objekt mit einem internen Zeiger

Beispielprogramm: OBJINTZG.CPP

Das Programm OBJINTZG.CPP ist unser erstes Beispiel für ein Programm mit eingebettetem Zeiger, mit dem wir dynamisch Speicher beschaffen.

In Zeile 8 deklarieren wir einen Zeiger auf eine Variable vom Typ int, aber es ist eben nur ein Zeiger, kein Speicher ist ihm tatsächlich noch zugewiesen. Deshalb stellt der Konstruktor in Zeile 22 eine Variable vom Typ int im Speicher bereit, die wir mit diesem Zeiger verwenden. Es ist Dir sicherlich klar, daß jedes der drei Objekte, die wir in Zeile 46 definieren, seinen eigenen Zeiger hat, der auf seine eigene Adresse im Speicher zeigt. Für jedes Objekt steht eine eigene dynamisch beschaffte Variable im Speicher zur Verfügung. Alle diese Variablen haben aber zunächst den Wert 112, da wir in Zeile 23 diesen Wert in jeder der drei Variablen speichern, je einmal pro Konstruktoraufruf.

In einem so kleinen Programm müssen wir uns schon sehr anstrengen, den verfügbaren Speicher voll auszuschöpfen, und mit dem, was wir tun, wird uns das aller Wahrscheinlichkeit nach auch nicht gelingen. Deshalb führen wir keinen Test durch, ob der Speicher, den wir anfordern, auch tatsächlich verfügbar ist. In einem "richtigen" Programm solltest Du aber testen, ob der Wert des zurückgegebenen Zeigers nicht NULL ist, um sicherzustellen, daß die Daten auch gespeichert werden können.

Die Methode mit dem Namen Setze() erwartet drei Parameter, von denen letzterer den Wert der neuen, dynamisch beschafften Variable setzt. Wir senden Nachrichten, diese Methode auszuführen, an zwei Objekte, die kleine und die große Box. Die Standardwerte der mittleren Box bleiben unangetastet.

Wir zeigen die drei Flächen gefolgt von den drei in der dynamisch beschafften Variable gespeicherten Werten aus und haben schlußendlich ein Programm, das einen Destruktor braucht, um vollkommen richtig zu funktionieren. Wenn wir einfach den Gültigkeitsbereich der Objekte verlassen, wie wir es tun, wenn wir die Funktion main() verlassen, bleiben uns die drei dynamisch beschafften Variablen im Speicher erhalten, nur zeigt nichts mehr auf sie. Sie sind nicht mehr adressierbar und deshalb nichts als verschwendeter Speicherplatz. Aus diesem Grund benötigen wir einen Destruktor, der die Variablen löscht (mittels delete), auf die die Zeiger mit dem bedeutungsschwangeren Namen Zeiger zeigen, je eine pro Aufruf. Bei einem solchen Aufruf (der wie wir wissen automatisch erfolgt, wenn ein Objekt zu existieren aufhört) weisen die Zeilen 38 und 39 den Variablen, die automatisch gelöscht werden, den Wert 0 zu. Zwar ist dies vollkommen sinnlos, möglich ist es aber doch.

In unserem speziellen Beispiel werden alle Variablen (auch die dynamisch beschafften) automatisch gelöscht, da wir zum Betriebssystem zurückkehren, das diese Aufgabe für uns übernimmt, wenn es das komplette Programm aus dem Speicher entfernt. Trotzdem zeugt es von gutem Programmierstil, aufzuräumen, wenn man mit dem Spielen fertig ist (dynamisch bereitgestellten Speicher nicht mehr benötigt).

Auf ein anderes Konstrukt sollten wir auch noch einmal kurz eingehen, nämlich auf die Methoden in den Zeilen 12 und 13, die wir inline implementieren. Wie wir in Kapitel 5 festgestellt haben, können Funktionen mit dieser Technik implementiert werden, wenn erstes und oberstes Ziel Geschwindigkeit ist, da die Funktionen im Code selbst stehen und nicht mit einem Funktionsaufruf verbunden sind. Da der Code für diese Methoden in der Deklaration steht, wir der Compiler ihn inline, also im Code, wo der Funktionsaufruf steht einfach an dessen Statt einsetzen, eine weitere Implementation des Codes der Methode ist nicht notwendig. Es handelt sich dabei allerdings nur um einen Vorschlag an den Compiler, das zu tun, er muß sich keineswegs daran halten und kann die Methode (oder Funktion) als solche implementieren.

Bedenke aber, daß wir am Verstecken unseres Codes interessiert sind, was durch die im vorigen Absatz diskutierte Vorgangsweise natürlich untergraben wird, da wir den kompletten Code offen zur Schau stellen. Oft aber wirst Du an der Geschwindigkeit mehr interessiert sein als am Verstecken von trivialem Code, denn nur solcher empfiehlt sich wirklich, inline implementiert zu werden. Kompiliere das Programm und führe es aus.

(weiter...)