Sie möchten einen Texteditor erstellen. Vielleicht ist es ein moderner Ersatz für Vi oder eine neue Version von Notepad. Es spielt keine Rolle. Das Ziel ist einfach: Benutzern die Bearbeitung von Standard-ASCII-Dateien ermöglichen.
Überlegen Sie, wie oft Programmierer diese Tools tatsächlich verwenden. Es ist ihre primäre Schnittstelle zur Maschine. Hier werden Gedanken zu Code. Natürlich möchten Sie, dass es sich richtig anfühlt. Sie möchten, dass es schnell geht. Sie möchten, dass es Ihren spezifischen Arbeitsablauf abwickelt. Also entscheiden Sie sich, Ihr eigenes zu bauen.
Die erste Hürde ist die Datenstruktur. Wie speichert man den Text im Gedächtnis? Sie benötigen eine Möglichkeit, die Charaktere schnell zu manipulieren. Ihr erster Instinkt? Textzeilen.
Sie schnappen sich ein Array. Ganz einfach. Eine typische Zeile umfasst 80 Zeichen. Eine typische Datei hat vielleicht 1.000 Zeilen. Sie deklarieren ein zweidimensionales Array:
„c
char doc[1000][80];
„
Das sind 80.000 Zeichen. Überschaubar. Sauber.
Doch dann kommt die Realität. Sie denken über Grenzfälle nach.
Bei einigen Dateien handelt es sich um umfangreiche Protokolllisten. Tausende Zeilen, jede kaum 10 Zeichen lang.
Andere Dateien sind spezielle Daten-Dumps. Eine Zeile kann 542 Zeichen enthalten, die Aminosäurepaare in einer DNA-Sequenz darstellen.
Und mit modernen Editoren können Sie mehrere Dateien gleichzeitig öffnen. Nehmen wir an, Sie begrenzen die Anzahl der geöffneten Dateien auf 10. Sie legen ein festes Limit von 1.000 Zeichen pro Zeile und 50.000 Zeilen pro Datei fest.
Nun sieht Ihre Erklärung so aus:
„c
char doc[50000][1000][10];
„
Sie rechnen mit den Zahlen. 50.000 mal 1.000 mal 10. Das sind 500 Millionen Zeichen.
Die meisten Computer können damit nicht umgehen. Selbst mit virtuellem Speicher ist es eine Belastung. Führen Sie drei Instanzen Ihres Editors auf einem Mehrbenutzersystem aus, und Sie verstopfen den Arbeitsspeicher. Es ist eine extravagante Verschwendung. Sie weisen Speicherplatz für den absoluten Worst-Case-Szenario zu, wenn die meisten Benutzer nur 100-Zeilen-Dateien bearbeiten, die 4.000 Bytes belegen.
Das Problem mit Arrays ist starr. Sie müssen die maximale Größe in jeder Dimension im Voraus angeben. Diese Dimensionen vervielfachen sich. Und wenn jemand versucht, eine Datei mit einer Zeile mit 2.000 Zeichen zu öffnen? Du hast kein Glück. Die Leitungslänge ist technisch gesehen unendlich. Man kann es nicht vorhersagen.
Aus diesem Grund gibt es Zeiger.
Wie Zeiger Speicherverschwendung beseitigen
Mit Zeigern können Sie dynamische Datenstrukturen erstellen. Anstatt statischen Speicherplatz im Voraus zu reservieren, weisen Sie während der Programmausführung Speicher aus dem Heap zu.
Sie nutzen genau die Menge an Speicher, die das Dokument benötigt. Keine Verschwendung. Wenn Sie eine Datei schließen, geben Sie diesen Speicher an den Heap zurück. Andere Teile des Programms können es verwenden. Speicher wird recycelt.
Es geht nicht nur darum, Platz zu sparen. Es geht um Flexibilität. Sie müssen die maximale Zeilenlänge nicht schätzen. Sie weisen zu, was Sie brauchen, wann Sie es brauchen.
Wenn Sie sich immer noch fragen, was ein Byte eigentlich ist oder wie sich „Mega“ und „Giga“ auf reale Einschränkungen übertragen lassen, lesen Sie sich über Bits und Bytes um. Dann komm zurück. Sie müssen die Hardwaregrenzen verstehen, um zu verstehen, warum statische Arrays hier versagen.
