Mit PRINT# können Dateien sequentiell beschrieben werden. Der Befehl folgt dabei denselben Regeln wie PRINT (siehe Kapitel 4.1), einschließlich der Komma- und Strichpunkt-Regeln. Auch TAB wird unterstützt. Die Ausgabe in der Datei entspricht genau dem, was Sie sonst im Programmfenster erwarten würden.

PRINT# eignet sich vor allem dann, wenn das Lesen der gespeicherten Daten über den Texteditor angenehm gestaltet werden soll, z. B. wenn Sie eine schön formatierte Ausgabe erreichen wollen (etwa eine tabellarische Darstellung) oder wenn ein spezielles textbasiertes Format, etwa HTML, genutzt werden soll. Wenn Ihr vorrangiges Ziel dagegen ist, die geschriebenen Daten mit geringem Aufwand wieder einzulesen, ist WRITE# möglicherweise die bessere Wahl. Hier werden die Parameter durch Kommata getrennt (ein Semikolon ist nicht zulässig), und diese Kommata werden auch in die Datei geschrieben. Außerdem werden Strings mit Anführungszeichen umgeben.

Für beide Befehle ist das Rautezeichen notwendig, da sonst nicht zwischen der Datei-Eingabe und der Tastatur-Eingabe unterschieden werden könnte. Aus diesem Grund werden wir bei der Datei-Ausgabe auch von PRINT# und WRITE# sprechen, auch wenn der Befehl tatsächlich nur PRINT bzw. WRITE lautet. In der Datei ausgabe.txt steht nun folgendes:

Beachten Sie bei der Dateiausgabe in der ersten Zeile die Auswirkung des Strichpunktes (direktes Aneinanderhängen) und des Kommas (Einrückung). Bei WRITE# werden die Daten, durch Komma getrennt, ohne Einrückungen direkt aneinandergehängt. WRITE# eignet sich daher nicht dazu, eine schön formatierte Ausgabe zu erhalten, sondern hat einen rein praktischen Nutzen. Die Daten können nämlich mit INPUT# problemlos wieder einzeln eingelesen werden.

Auch INPUT# und LINE INPUT# funktionieren grundsätzlich genauso wie die in Kapitel 5.1 behandelten Befehle zur Tastatureingabe. Wenn Sie die in Quelltext 16.4 gespeicherten Daten wieder einlesen wollen, können Sie folgendermaßen vorgehen:

INPUT# folgt denselben Begrenzungsregeln durch Kommata. Wenn Sie also eine Zeile einlesen wollen, die ein Komma beinhaltet, wird der Lesevorgang vor dem Komma beendet.³ Das kann so gewollt sein; wenn Sie aber Textdateien zeilenweise einlesen wollen, weichen Sie besser auf LINE INPUT# aus.

Auch die Funktionsversion INPUT() zum Auslesen einer festgelegten Zeichenzahl kann auf eine zum Lesen geöffnete Datei angewendet werden. Dazu muss allerdings die Dateinummer als zweiter Parameter angegeben werden (anstatt als erster), und es darf ihr auch kein Hash vorangestellt werden. Wenn Sie dagegen aus einer Unicode-codierten Datei lesen wollen, verwenden Sie stattdessen WINPUT().

Denken Sie daran, dass die Datei nur dann korrekt mit ENCODING "UTF-8" (oder anderen Unicode-Arten) geöffnet werden kann, wenn in der Datei das BOM gesetzt ist.

Falls Sie sich übrigens fragen, was in der sechsten Zeile die vier aufeinanderfolgenden Anführungszeichen bedeuten sollen: Auf diese Art und Weise können Sie ein Anführungszeichen auf der Konsole ausgeben. Das vorderste und hinterste Anführungszeichen der Vierergruppe begrenzt den String, und die beiden mittleren werden zusammen als ein Anführungszeichen interpretiert.

Zum Speichern binärer Daten verwenden wir den Befehl PUT#:

PUT# existiert auch als Funktion. Dann muss die Parameterliste mit Klammern umgeben werden; der Rückgabewert ist eine FreeBASIC-Fehlernummer (oder 0, wenn kein Fehler aufgetreten ist).

Die folgenden Beispiele dienen nur zur Demonstration der Syntax; der Code ist in dieser Form nicht lauffähig. Insbesondere kann der Pointer-Zugriff nicht ohne Reservierung des Speicherplatzes stattfinden.

Nicht alle Speichergrößen sind intuitiv. Verwenden Sie auf jeden Fall keine Rechenausdrücke, oder setzen Sie sie in ein CAST, um den Datentyp sicherzustellen. Auch bei Strings variabler Länge müssen Sie aufpassen, damit Sie beim Einlesen wieder die richtige Länge verwenden.

Besonders praktisch ist, dass Sie mit PUT# auch komplette UDTs schreiben können. Es gibt dabei jedoch eine Einschränkung: Strings variabler Länge funktionieren genauso wenig wie Pointer-Inhalte. Der Grund dafür ist ganz einfach: Ein Pointer selbst ist lediglich ein INTEGER-Wert mit der Adresse auf den Inhalt. Diesen zu speichern bringt nichts, da der tatsächliche Inhalt verloren geht. Bei Strings variabler Länge ist es dasselbe, denn auch dieser verweist nur auf den tatsächlichen String-Inhalt. Wenn Sie im UDT aber nur Zahlenwerte und Strings fester Länge verwenden, ist ein Speichern und Laden des gesamten UDTs problemlos möglich. Ein Beispiel dafür finden Sie in Quelltext 16.8.

Der Lesebefehl GET# ist bis auf einen weiteren optionalen Parameter genauso aufgebaut wie PUT# und kann ebenfalls als Funktion eingesetzt werden.

gelesen ist eine Variable, in der gespeichert wird, wie viele Byte tatsächlich eingelesen wurden. Damit können Sie überprüfen, ob alle Daten korrekt gelesen wurde oder ob versucht wurde, hinter dem Dateiende zu lesen.

Als Beispiel wollen wir die Abmessungen eines BMP-Bildes auslesen. Wie viele andere Dateitypen besitzt BMP einen Header, in dem u. a. Informationen zu Bildabmessung, Auflösung, Farbtiefe, Komprimierung usw. gespeichert sind. Diese Daten besitzen eine feste Position innerhalb der Datei und können daher gezielt angesteuert werden.

Hinweis: Die Höhe des Bildes kann (selten) negativ angegeben sein, um damit eine Datenspeicherung von oben nach unten (statt von unten nach oben) zu kennzeichnen.

Die Verwendung des richtigen Datentyps ist von entscheidender Bedeutung. In Quelltext 16.7 beispielsweise muss ein LONG (bzw. ein INTEGER<32>) verwendet werden; ein INTEGER würde in einem 64-Bit-System zu falschen Werten führen, da es sich dort um ein INTEGER<64> und damit um einen zu großen Datentyp handelt.

Sehen wir uns zum Thema Datentyp-Größen noch folgendes Beispiel an:

Was genau schiefgelaufen ist, sieht man, wenn man sich die Hexadezimalwerte ansieht:

Gespeichert wurde erst das USHORT &h1234 (zwei Byte) — und zwar, da es sich um ein Little-Endian-System⁴ handelt, in der Reihenfolge &h34 &h12 — und dann das UBYTE &h56. In der Datei steht nun die Bytefolge &h341256. Beim Auslesen wird erst ein UBYTE extrahiert, nämlich &h34, und als zweites ein USHORT mit der Byte-Reihenfolge &h12 &h56. Das USHORT wird, wieder wegen des Little-Endian-Systems, als &h5612 zusammengesetzt.
Hätten Sie den Inhalt der Datei in einen ausreichend langen STRING gelesen, wären die Byte-Werte als ASCII-Codes interpretiert worden (in diesem Fall als CHR(&h34, &h12, &h56)).

Auch die Verwendung eigener UDTs soll kurz demonstriert werden. Wir verwenden ein UDT mit Unter-UDT, denn auch das stellt keine Schwierigkeit dar, solange in keiner der Ebenen Strings variaber Länge oder Pointer vorkommen.

Sie sehen, dass Sie in eine mit BINARY geöffnete Datei sowohl schreiben als auch aus ihr lesen können, was insbesondere die Verwendung mit Datensätzen sehr bequem macht. Noch eine kurze Erläuterung zur GET#-Zeile: Der erste Datensatz startet an Position 1 und benötigt SIZEOF(TypTest) Byte an Speicherplatz. Dementsprechend startet der zweite Datensatz an Position 1+SIZEOF(TypTest) und der dritte bei 1+2*SIZEOF(TypTest). Zur Erinnerung: SIZEOF() gibt die Größe einer Variablen oder eines Datentyps an.

Um eine Zeichenkette korrekt aus der Datei auszulesen, müssen Sie ihre Länge kennen. Und ebenso wichtig: Das Programm muss wissen, wie lang der auszulesende String sein soll. Das können Sie auf zwei Wegen erreichen:

Die Länge des Strings wird nicht automatisch mitgespeichert. Bei variabler Länge sind Sie daher selbst dafür verantwortlich, die Länge zu speichern. Ich empfehle dazu, erst die Länge als Zahlenwert zu speichern und dann den String dahinter abzulegen. Beim Lesevorgang lesen Sie dann wieder erst die Länge aus, präparieren dann die Stringvariable so, dass sie die richtige Länge besitzt, und lesen den String ein.

In Zeile 11 wird in ladestring eine Zeichenkette aus der benötigten Anzahl an Leerzeichen erzeugt. Das ist sehr effektiv, aber lediglich eine von mehreren Möglichkeiten. Wichtig ist nur, dass ladestring vor dem Lesevorgang die richtige Länge hat.

Die Position des Dateizeigers können Sie jederzeit mit SEEK setzen oder lesen. Im ersten Fall wird SEEK als Prozedur eingesetzt, im zweiten Fall SEEK() als Funktion.

Das erste Setzen des Zeigers hätte natürlich auch über den zweiten Parameter von PUT erfolgen können. Oft ist es programmiertechnisch jedoch sinnvoller, zunächst die gewünschte Ausgangsposition herzustellen und anschließend die Schreibvorgänge durchzuführen.

Eine weitere Funktion zum Ermitteln (jedoch nicht zum Setzen) des Dateizeigers ist LOC(). Diese gibt nicht die aktuelle Position an, sondern das zuletzt gelesene Element. Bei Dateien, die mit BINARY geöffnet wurden, ist daher der Rückgabewert von LOC() immer um genau 1 kleiner als SEEK(). Bei mit RANDOM geöffneten Dateien wird der zuletzt gelesene Datensatz zurückgegeben, und bei sequentiellen Dateien nimmt der Compiler eine Datensatzlänge von 128 Byte an (LOC(dateinummer) = (SEEK(dateinummer)-1)\128.) Allein schon wegen dieser eher unhandlichen Berechnungsformel sollten Sie auf LOC() verzichten und stattdessen SEEK() verwenden. LOC() dient lediglich der Rückwärtskompatibilität zu QuickBASIC.

Dem aufmerksamen Leser sollte nicht entgangen sein, dass vor dem Parameter dateinummer in der Funktion SEEK() kein Rautenzeichen steht. Aufgrund der Compiler-Syntax können innerhalb von Funktionen keine Parameter mit Rautezeichen eingesetzt werden. Dies betrifft auch LOC() und die im Folgenden aufgeführten Funktionen EOF() und LOF(), aber auch selbst definierten Unterprogramme. OPEN, CLOSE, GET#, INPUT# usw. werden beim Compiliervorgang speziell behandelt.

Die klassische Variante für sequentielle Daten ist EOF(). Diese Funktion gibt zurück, ob das Dateiende erreicht wurde (-1) oder nicht (0). Auch wenn der Dateizeiger mit SEEK hinter das Dateiende gesetzt wurde, liefert EOF() -1 zurück.

Besonders interessant ist EOF() im Zusammenhang mit dem Dateimodus INPUT. Bei den Dateimodi OUTPUT und APPEND gibt EOF() immer -1 zurück, unabhängig von der tatsächlichen Position des Zeigers.

Quelltext 16.11 demonstriert das Einlesen einer kompletten sequentiellen Datei. Wenn Sie den Quellcode unter dem Namen test.bas speichern, können Sie damit genau diesen Quellcode auf dem Bildschirm ausgeben.

EOF() kann zwar auch bei mit BINARY geöffneten Dateien eingesetzt werden, allerdings bietet sich dort LOF() in der Regel eher an. LOF() gibt die Länge der geöffneten Datei in Byte an, und vor dem Zugriff auf die gewünschten Daten kann dann überprüft werden, ob der benötigte Datenbereich überhaupt innerhalb der Datei liegt.

Zur Erläuterung: Wie schon in Quelltext 16.8 beginnt Datensatz 1 an der Stelle 1 und ist SIZEOF(TypDatensatz) lang (hier 16 Byte; siehe auch Kapitel 7.3). Der fünfte Datensatz beginnt dementsprechend an der Stelle 1+(5-1)*SIZEOF(TypDatensatz). Ist die Datei kürzer als 5*SIZEOF(TypDatensatz), dann ist der fünfte Datensatz nicht vorhanden oder unvollständig. Anstatt zu versuchen, den Datensatz einzulesen — der Lesevorgang schlägt dann fehl und datensatz wird auf den Initialwert gesetzt — fängt das Programm den Fehler mit einer Meldung ab.

Insgesamt gibt es drei Standard-Datenströme:

Interessant sind die Standard-Datenströme, weil sie auf ein anderes Ein- bzw. Ausgabemedium umgeleitet werden können. Sie können Daten z. B. statt von der Tastatur auch aus einer Datei einspeisen oder umgekehrt die Ausgabe in eine Datei umleiten. Nehmen wir an, Sie haben ein Programm namens test.exe, das von stdin liest, nach stdout ausgibt und Fehlermeldungen nach stderr schreibt. Sie können dieses Programm nun über die Konsole starten:

Die Eingabe erfolgt, wie gewohnt, über die Tastatur, und sowohl die Ausgabe als auch die Fehlermeldungen erscheinen im Konsolenfester. Um die Ausgabe in eine Datei umzuleiten, können Sie stattdessen folgendermaßen starten:

Die Spitzklammer legt die Ausgabedatei fest. Fehlermeldungen (stderr) werden weiterhin auf der Konsole ausgegeben, die regulären Meldungen (stdout) dagegen in die Datei ausgabe.txt geschrieben. Mit der einfachen Spitzklammer (erste Befehlszeile) legen Sie die Datei neu an und überschreiben die alten Inhalte. Die doppelte Spitzklammer (zweite Befehlszeile) bewirkt, dass die Ausgabe an die bereits bestehende Datei angehängt wird. Wenn Sie die Ausgabe und die Fehlermeldungen getrennt in zwei verschiedene Dateien schreiben wollen, können Sie folgendermaßen vorgehen:

Die 2 steht für den Datei-Deskriptor von stderr, gibt also an, dass nicht stdout, sondern stderr in die Datei fehler.txt umgeleitet werden soll. (Sie hätten bei der ersten Spitzklammer auch den Datei-Deskriptor +1+ hinzuschreiben können, aber da das der Standard ist, kann es weggelassen werden. Der Datei-Deskriptor wird also beim Aufruf benötigt, um stdout von stderr zu unterscheiden.) Um die Eingabedatei umzuleiten, d. h. um die Eingabe aus einer Datei zu lesen, drehen Sie die Spitzklammer um (auch hier kann der Datei-Deskriptor 0 dazugeschrieben werden):

Eine Umleitung von stdin findet oft auch über eine Pipe statt — das ist die Verkettung zweier Programme hintereinander. Die Ausgabe des ersten Programmes wird direkt als Eingabe für das zweite Programm weitergereicht:

All diese Umleitungen der Standard-Datenströme funktionieren in Ihrem Programm allerdings nur, wenn Sie dort einen oder mehrere dieser Datenströme öffnen.

stdin und stdout werden über OPEN CONS geöffnet, im ersten Fall im Dateimodus INPUT, im zweiten im Dateimodus OUTPUT. Wenn Sie sowohl stdin als auch stdout öffnen wollen, müssen Sie zwei verschiedene Dateinummern verwenden.

Zum Öffnen von stderr greifen Sie auf OPEN ERR zurück. Auf den Datenstrom kann nur schreibend zugegriffen werden, weshalb kein Dateimodus angegeben werden muss — die Angabe wird ignoriert.

Quelltext 16.14 verwendet zur Demonstration alle drei Standard-Datenströme:

Wenn Sie das Programm „normal“ starten, d. h. ohne Umleitungsangaben, gibt es zunächst auf der Konsole die Statusinformation aus (Zeile 11), wartet dann auf eine Benutzereingabe (diese wird während der Eingabe nicht angezeigt!) und gibt diese anschließend auf der Konsole aus. Um die Umleitung zu testen, können Sie z. B. folgenden Aufruf verwenden:

(wobei davon ausgegangen wird, dass das Programm zu test.exe compiliert wurde und eine Eingabedatei namens eingabe.txt existiert — eine eventuell existierende ausgabe.txt und status.txt wird beim Aufruf überschrieben).

Standard-Datenströme können zwar mit CLOSE geschlossen, dann aber nicht mehr geöffnet werden. Um sie komplett zurückzusetzen (damit können Sie sie theoretisch wieder neu öffnen), verwenden Sie den Befehl RESET 0 für stdin bzw. RESET 1 für stdout. Allerdings gibt es in der Regel keinen Grund dafür, mehrmals denselben Standard-Datenstrom zu öffnen. Sie können ihn problemlos bis zum Ende des Programmes geöffnet halten.

Der Vollständigkeit halber soll an dieser Stelle auch OPEN SCRN erwähnt werden, das ebenfalls die Standardausgabe öffnet, jedoch nicht die Standardeingabe. Wenn Sie versuchen, von einer mit OPEN SCRN geöffneten Datei zu lesen, werden Sie dafür mit einer Endlosschleife belohnt. Der Befehl existiert hauptsächlich zur Rückwärtskompatibilität und bietet keine Vorteile im Vergleich zu OPEN CONS.

Für die direkte Kommunikation Ihres Programma mit einem anderen Programm unterstützt FreeBASIC unidirektionale Pipes. Das sind Datenströme, die jedoch nur in eine Richtung laufen, nämlich vom aufgerufenen Programm aus in Richtung des aufrufenden Programmes. OPEN PIPE startet ein Programm (bzw. einen Shell-Befehl) und leitet dessen Ausgabe in einen Datenpuffer um, der über INPUT# gelesen werden kann. Dies kann folgendermaßen aussehen:

Hilfreich kann dieser Befehl sein, wenn Sie mit Ihrem Programm einen Konsolenbefehl aufrufen und dessen Rückgabe verarbeiten wollen. Über EXEC (siehe Kapitel 17.3) ist es ebenfalls möglich, einen Rückgabewert eines Programmes abzurufen, dieser ist jedoch sehr eingeschränkt und eigentlich nur als Fehler-Rückgabe gedacht. OPEN PIPE erlaubt Ihnen dagegen jede beliebige Rückgabe, die dann nur noch entsprechend ausgewertet werden muss.