Das deutsche QBasic- und FreeBASIC-Forum

[Berkeley]

Wenn man OPEN mit FOR INPUT/OUTPUT statt mit FOR BINARY benutzt, dann lesen/schreiben GET# und PUT# nur eine stark begrenzte Zahl an Bytes - als würde man einen Textstring erwarten.

[grindstone]

Aus der Referenz:

[nemored]

Oder von der anderen Seite her argumentiert:
FOR INPUT und FOR OUTPUT öffnet die Datei im sequentiellen Modus, ist also auch auf einen sequentiellen Dateizugriff ausgerichtet, nicht auf einen wahlfreien Zugriff.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[Berkeley]

[nemored]

Sequentielle Daten werden durch bestimmte Zeichen voneinander abgegrenzt (in diesem Fall Komma und Zeilenumbruch). Dass GET# zur Verwendung mit dem Dateimodus BINARY (und RANDOM) vorgesehen ist, steht bereits in der deutschen und der englischen Referenz. Dass GET# im Modus FOR INPUT anders arbeiten sollte als vom Modus FOR INPUT vorgesehen (nämlich bis zum Trennzeichen zu lesen), ist zunächst einmal nicht zu erwarten.

Welche FreeBASIC-Anleitung du meinst, weiß ich nicht. Falls du die Referenz meinst (eine Referenz ist keine Anleitung), da kann ich schon einen Vermerk aufnehmen - allerdings fällt mir da gerade nichts besseres ein als
"Achtung: Wenn Sie GET# in einem anderen Dateimodus verwenden als vorgesehen, kann es sein, dass Sie andere Ergebnisse erhalten als Sie erwarten."
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[Berkeley]

[nemored]

Das Problem besteht glaube ich darin, was sequentieller Zugriff eigentlich ist. Auch wenn alle Daten am Stück mit einem einzigen GET ausgelesen werden - oder auch in selbst gewählten Blockgrößen nacheinander - handelt es sich dabei nicht um sequentielles Lesen im eigentlichen Sinn. "Wahlfreier Zugriff" zeichnet sich nicht nur dadurch aus, dass du an beliebiger Stelle mit dem Lesen beginnen kannst, sondern auch durch die Möglichkeit, die gelesene Menge selbst zu bestimmen.

Ich habe den Artikel zu FOR INPUT mal etwas ausgebaut; vielleicht ist es so klarer.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[Berkeley]

Danke für deine ehrenamtliche Arbeit an der Referenz und dem Forum...

Es ist halt nicht gerade "BASIC-like", also für Programmieranfänger. Mindestens sollte der Compiler dann erzwingen, dass man für GET#/PUT# "BINARY" verwenden muss. Immerhin kommt FreeBASIC meiner Vorstellung eines perfekten (modernen) BASIC immer noch am nächsten.

[nemored]

Dass BASIC (ganz allgemein) wirklich "BASIC-like" wäre, halte ich nur oberflächlich betrachtet für richtig. Schon der normale INPUT-Befehl ist aus meiner Sicht unnötig kompliziert - was soll diese Unterscheidung mit Strichpunkt oder Komma, mit dem man den Anweisungstext von der Variablenliste abtrennen kann? Und das ist keine Erfindung eines einzelnen BASIC-Dialekts, sondern in allen Dialekten vorhanden, mit denen ich mich bisher beschäftigt habe.

Eine Compiler-Warnung beim Einsatz von GET# auf sequentiell geöffnete Dateien wäre sicher nciht schlecht, ist aber wohl nicht umsetzbar. Ohne Laufzeitanalye kann der Compiler nicht wissen, in welchem Dateimodus die Datei geöffnet ist. Es ist ja z. B. auch möglich, die Datei im Hauptprogramm zu öffnen und die Dateinummer an ein Unterprogramm zu übergeben, oder umgekehrt. In einer interpretierten Sprache kann man dann immer noch einen Fehler werfen; in einem compilierten Programm bringt ein Laufzeitfehler viel Ärger mit sich und wird daher nur in Notfällen geworfen.
(Auch das ist ein Grund, der gegen die "BASIC-likeness" spricht - Compilersprachen sind einfach nicht "anfängerfreundlich".)
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[grindstone]

Das ist der alte Konflikt Sicherheit vs. Flexibilität.

Ein kleines bisschen Gehirnschmalz sollte der Programmierer schon noch investieren (müssen).

Gruß
grindstone
_________________
For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen!

[Berkeley]

[hhr]

Ich verstehe das Problem nicht. Man muss doch immer ausprobieren, ob etwas so funktioniert, wie man es wünscht.
Kann mir jemand ein Beispiel nennen, mit dem ich das Problem verstehen kann?

Das folgende Beispiel funktioniert mit Binary genauso wie mit Output/Input:

[Berkeley]

[hhr]

Tatsächlich! Ich habe c16x8.fnt aus retrogra mit folgendem Beispiel kopiert und beide Kopien mit dem Editor geöffnet. Jetzt weiß ich, was gemeint ist.
Könnte das ein Bug sein? Kann das jemand erklären?

(Die Pfade muss man anpassen.)

[hhr]

Ich habe selbst eine 80KB Textdatei mit Buchstaben erstellt. Damit ist alles in Ordnung. Es wird alles richtig kopiert.
Kann es sein, dass in c16x8.fnt Zeichen oder Zeichenkombinationen vorkommen, die get im Input Modus nicht mag?
Und wenn ja, was ist das, was get im Input Modus nicht mag?

[Berkeley]

[hhr]

Bei get im Input Modus scheint es das EOF-Zeichen Strg+z (&h1a) zu sein. Wenn &h1a in der Datei vorkommt, wird an der Stelle abgebrochen.

Bei get im Binary Modus wird alles gleich behandelt.

https://de.wikipedia.org/wiki/End_of_File

Das folgende Beispiel kopiert 'c16x8.fnt'. Original und Kopie sind identisch:

[grindstone]

[hhr]

Genau! Get sollte man bei einer für Input geöffneten Datei nicht verwenden. Es sei denn, man wollte nur bis zum ersten &h1A lesen.

Bis jetzt dachte ich, EOF wäre das Ende der Datei. Dass &h1A EOF bedeuten kann, habe ich bis jetzt nicht gewusst.

Dass man Put bei einer für Output geöffneten Datei auch nur mit Vorsicht verwenden sollte, ist wohl nur konsequent.

[Berkeley]

Es ist schlicht Unsinn, dass man hier unterscheidet. Man nimmt auch keine Schlitzschrauben, sondern Torx ! Klarer Fehler von der Herstellerseite...

Es ist Sache vom Betriebssystem, das Dateiende festzustellen, und das hat bessere Mittel als so was Primitives und Fehleranfälliges wie ein Abschlussbyte. Natürlich sollte man INPUT# und GET# nicht gemischt einsetzen, wenn man nicht weiß was man tut. Dass sich GET# in einer Modusunterscheidung, die es nach POSIX gar nicht gibt, anders verhält, ist... alternatives logisches Denken. Es ist eine Funktionalität, die man EXTRA einprogrammiert hat, und das auch noch anstatt einfach einen Fehler zu schmeißen "Binary-Modus verwenden !"...