Das deutsche QBasic- und FreeBASIC-Forum

[Westbeam]

Bin mir nicht ganz sicher, ob es nicht doch nach Linux-spezifische Fragen gehört, da ich mir nicht sicher bin, ob dies auch bei Windows so ist...

Ich möchte ins Terminal(bei Windows die cmd-Konsole) schreiben. Dies klappt soweit auch ganz gut. Allerdings auch nur, solange keine andere Datei offen ist. Sobald dies geschieht, wird einfach nicht ins Terminal geschrieben. Mein Code zum Öffnen der Datei und der Konsole schaut so aus:

[Jojo]

jou, da sieht man mal wieder, wie sinnvoll die datei-handles von qb/fb sind.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[28398]

Und da nennt man mich Freebasichasser!!!eins!!!!elf!!!!

[Sebastian]

Hallo!

Im Unterschied zur Handle-Philosophie von fopen u.ä. ist es hier so, dass FREEFILE nur die nächste freie Handle-ID zurückgibt. Das Handle wird nicht reserviert und es wird kein I/O-Stream erzeugt, sondern die ID bleibt so lange frei, bis tatsächlich mit OPEN eine Datei mit diesem Handle geöffnet wird.

[Jojo]

[28398]

[Sannaj]

Naja, das sind halt die Maken von FreeBASIC und seine QB-Abwährscompatibilität. Konsequent währe es eigentlich jetzt das Filehandling System suzessif zu ersetzten. Glüglicherweise verlangen die meisten Dateifunktionen ein # vor dem Dateihander.
Ich hätte zwei Vorschläge, wie man das alternative Dateinutzungskonzept umsetzten könnte:
1. Wie in C mittels eines speziellen "file ptr"- Datendescriptors. Die Dateifunktionen (print, input, get, eof, ...) müssten halt entsprechend überladen werden, open und close bräuchten einen neuen Aufbau. Die alten Dateinummern entsprächen Indexen auf den Array #, der aus 255(oder wenger?) Dateideskriptoren bestünde. (Den es nur gibt, wenn man ihn auch braucht.)
2. Da wir ja jetzt Objektorierentiert werden, verwenden gib es einfach ein vordefiniertes "file"-Objekt. Das dann print, input, get, eof, open usw. als Methoden enthält. Die alten Strukuren beständen immer noch zwecks Kompatiblität.

Anstelle beide Arten paaralle anzubieten, könnt man für die neue Methode zusammen mit ein paar ähnliche Änderungen. (z.B. der Einführung einer "main" Funktion) eine eigene Dialektform aufmachen.

[MOD]

Man muss sich doch einfach nur merken, dass FreeFile eine Zahl zurückgibt, nichts weiter. Diese wird als Dateihandler erst dann aktiv gesperrt, wenn man den "stream" mit Open öffnet.

Open kann man übrigens auch als Funktion aufrufen sodass ein Fehlerwert zurückgegeben wird.

Noch ein Dialekt? Wir haben doch schon vier..ich bin eher dafür alles außer -lang fb und qb komplett rauszustreichen. Eine explizite main-Funktion fände ich ehrlich gesagt auch nicht besonders toll. Das ist zusätzlicher Schreibaufwand, den man eigentlich gar nicht braucht. Das schöne an FB ist doch, dass man einfach drauf losarbeiten kann un mit wenig Zeilen schon ein funktionsfähiges Programm erhält. Zudem wirkt der globale Bereich in FB so wie eine main-Funktion und man kann genauso argc und argv abfragen und einen Returnwert festlegen.

[Sannaj]

Ja gut, das mit der main-Funktion ist Meinungssache. Ich hab das hauptsächlich angeführt, um ein Beispiel für ein anderes Präfunktional-Relikt zu liefern. Außerdem beforzuge ich eine klare main-Fuktion persönlich.

Bei der Sache mit den Dialektformen stimm ich dir voll und ganz zu. Zum Glück wird -lang depressed eh bald abgeschaft. Also Kompromiss dafür, das FreeBasic neu Elemente einführen kann ist das aber richtig.

[MOD]

Alle neuen Elemente landen immer in -lang fb, das war schon immer so. Dass -lang deprecated abgeschafft werden soll ist mir neu, zumindest gibt es dazu meines Wissens keine aktuellen Entwicklungen. Langfristig vermutlich schon, allerdings kann das noch lange dauern.

Laut ToDo soll mal eine explizite main() kommen, aber auch die implizite Version bleibt bestehen. Ob das noch so sein soll kann ich ja mal rausfinden, zumindest war es mal so geplant.

[nemored]

Ich glaube nicht, dass -lang deprecated so schnell verschwindet. Immerhin stellt das sicher, dass ältere Quellcodes compilierbar bleiben, und besonders störend ist so ein zusätzlicher Dialekt für den Endnutzer ja nicht.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[Sannaj]

Ich finde eigentlich auch, das zusätzliche Dialekte abgesehen vom allgemeinen Image BASIC's nicht schaden. Zu der Sache mit depressed (Zitat von http://www.freebasic.net/wiki/wikka.php?wakka=CompilerOptforcelang):

[Jojo]

[Sannaj]

Ich hatte ehr an das Argument der fürtbaren Dialektisierung BASICs gedacht, aber deines zählt auch.