So, nach längerer, einem privaten Projekt geschuldeten Pause, nun endlich der nächste Artikel in der Reihe zum Programmieren mit C++. Im letzten Artikel haben wir uns allgemein mit dem Thema Datentypen und insbesondere einem bestimmten Typ, nämlich den Arrays, beschäftigt. Dabei ist uns ein Problem begegnet: wir können zwar wunderbar Arrays mit einer genau bekannten Größe deklarieren – ein Array mit erst zur Laufzeit bekannter Größe können wir aber noch nicht anlegen, da der Compiler nicht weiß, wie viel Speicherplatz er auf dem Stack für das Array reservieren soll. An dieser Stelle kommt nun ein neuer Speicherbereich ins Spiel, der uns bei der Lösung dieses Problems hilft: der Heap.
Nun kann man sich natürlich fragen, warum hier überhaupt ein Problem existiert; warum kann der Programmcode nicht einfach so durch den Compiler übersetzt werden, dass beim Anlegen eines Arrays mit erst zur Laufzeit bekannter Größe einfach der benötigte Speicherplatz auf dem Stack reserviert wird?
Wir erinnern uns: Variablen stellen im Programmcode lediglich eine Referenz auf eine bestimmte Speicherzelle dar, die relativ zum ebp
(extended base pointer, ein in einem Register gespeicherter Wert) angegeben wird. Der ebp
ändert sich auch bei jedem Funktionsaufruf. Um dieses Konzept aber umsetzen zu können, muss für alle Variablen innerhalb einer Funktion die genaue Distanz vom ebp
bekannt sein, und zwar bereits in dem Moment, in dem das Programm compiliert wird (da hier die Variablen zu relativen Speicheradressen aufgelöst werden). Auf dem Stack können deswegen nur feste, das heißt zur Compile-Zeit in ihrer Größe bekannte Speicherbereiche reserviert werden. Hätte man einen variablen Bereich, wüsste man für nachfolgende Variablen ja gar nicht, ab welcher Adresse (relativ zum ebp
) man sie referenzieren sollte.
Um das Dilemma zu lösen, wird also ein weiterer Speicherbereich benötigt, und zwar der bereits erwähnte Heap. Ebenso wie der Stack ist der Heap ein für ein Programm reservierter Bereich im Arbeitsspeicher. Er arbeitet im Unterschied zu jenem aber nicht streng linear – neue Daten können also an beliebigen (noch nicht belegten) Stellen abgelegt und wieder gelöscht werden. Er ist damit perfekt geeignet, um unsere Arrays mit unbekannter Größe zu verwalten.
Erinnern wir uns kurz: ein Array mit bekannter Größe wird in C++ folgendermaßen angelegt:
int as[10];
Obschon es logisch erscheint, können wir ein Array unbekannter Größe nicht so anlegen (die Variable n
wird mit einem beliebigen Wert belegt):
int n; ... n = ... ... int as[n];
Stattdessen benötigen wir einen anderen Mechanismus. Insbesondere müssen wir dem Compiler mitteilen, dass das Array auf dem Heap und nicht auf dem Stack angelegt werden soll. Zu diesem Zweck verfügt C++ über ein eigenes Schlüsselwort: new
. Benutzt werden kann es auf die folgende Art und Weise:
int n; ... n = ... ... int* as = new int[n];
Die Schlüsselzeile ist diese hier:
int* as = new int[n];
Fangen wir von hinten mit dem einfachen an: new int[n]
. Dieser Ausdruck bewirkt einfach, dass der Compiler veranlasst, ein Array der Länge n
(die erst zur Laufzeit bekannt ist) auf dem Heap anzulegen, oder, um genauer zu sein: im Heap wird ein Speicherbereich der Länge n * 4 Bytes
(ein int
-Wert benötigt 4 Bytes Speicher) reserviert.
Das Gleichheitszeichen =
deutet zudem an, dass der Ausdruck einen Wert zurückgibt. Und in der Tat: das “Ergebnis” eines new
-Ausdrucks ist immer die Speicheradresse im Heap, ab welcher der gewünschte Speicherbereich reserviert wurde. Diese wird ja benötigt, um den Speicherbereich später wieder aufzufinden.
Bleibt nur noch die seltsame Art der Variablendeklaration mit dem Stern, konkret das int* as
zu klären. Aber auch das ist im Grunde einfach: hier wird lediglich eine Variable as
deklariert, welche vom Typ int*
ist. Und was ist nun int*
für ein Typ? Ganz einfach: ein Typ, welcher eine Adresse (durch den Stern *
markiert) speichert, ab welcher Integer-Werte (durch int
markiert) gespeichert werden. Eine Adresse ist (auf einem 32-Bit-System) übrigens immer 4 Byte groß (auf einem 64-Bit-System dann 8 Byte).
Kommentare (8)