ObjectiveCeeds › Objective-C: Speicherverwaltung zu Fuß

Objective-C: Speicherverwaltung zu Fuß

Von Manfred Kreß

Seite 1 von 6



In diesem Artikel wird eine Speicherverwaltung, wie sie das Foundation Framework für Objective-C bietet selbst entwickelt um die Funktionsweise klar zu machen. Darüber hinaus, soll auch noch eine einfache String und Array Klasse entwickelt werden um den "Retain Count Mechanismus" anzuwenden.

Schauen wir uns am besten einmal die Speicherverwaltung in C an. Dynamischer Speicher wird mit malloc() beim Betriebsystem reserviert und mit free() freigegeben. Es ist eine relativ simple Tatsache, das es für jede Allocation auch ein Deallocation geben muss.
char *aBuffer;
aBuffer = malloc ( 256 * sizeof(char) );
/*
/ do something with aBuffer
*/
free ( aBuffer );
Obwohl die Sache zunächst sehr einfach aussieht, ist die Speicherverwaltung in c ein großes Problm. Stelllen sie sich sich vor, sie haben es mit einem komplexeren Programm zu tun. Es gibt Funktionen, die ihnen Zeiger auf reservierten Speicher zurückgeben. Und ein Zeiger wird an vielen Stellen gespeichert und verwendet, vielleicht sogar in Bibliotheks „Objekten“, die den Zeiger wiederum weiterreichen, ohne das sie als Anwender wissen, welche „Objekte“ den Speicherbereich noch brauchen und darauf Zugriff haben. Analog verhält es sich in Objective-C. Ein Objekt hat eine Methode Speicher zu reservieren und eine um ihn wieder freizugeben. Es ist eigentlich unmöglich, das ein Entwickler noch die Übersicht darüber behält, wie viele andere Objekte noch einen Zeiger auf ein Objekt benötigen. Hinzu kommen noch Interaktionen mit dem Anwender die die Sache noch erschweren. Stellen sie sich vor sie haben Strings in einem Array gespeichert. Das Array Objekt muss nun einen Zeiger auf jeden einzelnen String behalten. Der Anwender hat die Möglichkeit einen String in einem separaten Fenster zu editieren. Also wird der Zeiger auf den String an den Editor übergeben und dieser muss nun den Zeiger so lange behalten bis die Bearbeitung abgeschlossen ist. Nun haben schon zwei Objekte einen Zeiger auf den String. Der Anwender entscheidet sich den String zu löschen. Setzten wir nun den Speicher einfach im Editorobjekt frei, hat unser Array einen nil Pointer. Wenn wir vergessen Speicher im richtigen Moment freizugeben bekommen wir Speicherlecks (Memory Leaks). Speicher, auf den kein anderes Objekt mehr einen Zeiger hat ist noch für die Anwendung reserviert. Der Speicherverbrauch bläht sich auf. Geben wir Speicher zu früh frei, d.h. wenn ein anderes Objekt noch einen Zeiger auf diesen Speicherbereich hat sprechen wir von einem „Dangling Pointer“. Das Objekt das den Zeiger hält, schickt nun vielleicht Nachrichten an ein Objekt, das es gar nicht mehr gibt. Vielleicht wurde der Speicher schon einem Objekt anderen Typs zugewiesen. Folge solcher Messages sind meist Programmabstürze.

nächste Seite »
Seite: 1 von 6


Objective-C: Speicherverwaltung zu Fuß

Ein Root Objekt
Eine String Klasse
Die erste Anwendung
OCPet im Einsatz
Eine Array Klasse