Das deutsche QBasic- und FreeBASIC-Forum

[TimesChange]

Ich versuche gerade, ein Programm von QuickBasic auf FreeBasic zu portieren.

In Quickbasic hatte ich einigen Subs mit Marken und GOSUB - RETURN gearbeitet. Das hatte den gewissen Vorteil, dass alle Variablen innerhalb dieser Sub natürlich auch für den Abschnitt gültig sind, zu dem ich mit GOSUB springe.
In FreeBasic darf ich das nicht mehr, und muss diese Prozeduren also in eigene Subs oder Functions auslagern, und die erforderlichen Variablen als Argumente übergeben.
Das ist zwar umständlich, hat aber zumindest geklappt, bis ich in einem Fall eine Fehlermeldung bekomme.

Hier ein (sinnloses) Testbeispiel, das NICHT funktioniert:

[nemored]

[TimesChange]

Ähm ja, "L" war Mist, sollte ERG ausgeben. Ist aber eh nur ein Testprogramm, das irgendwas verwursteln soll.

Entscheidend ist die Fehlermeldung, hätte ich vielleicht gleich anhängen sollen:

[nemored]

Und, klappt denn meine Verbesserung für deine Zwecke?
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[TimesChange]

Nein, obige 4 Fehler bekomme ich auch mit Änderung.

Das Codebeispiel habe ich nur gemacht, da ich irgendeine Subroutine mit einem Array mit benutzerdefinierten Daten aufrufen wollte, um die Fehlermeldung zu zeigen.

[nemored]

[RockTheSchock]

[TimesChange]

Oh, sorry, ich habe nicht bemerkt dass du noch bisschen mehr korrigiert hast als nur das "L".
Wenn ich meine ganzen "Verschreiber" korrigiere, klappts auch bei mir

Den eigentlichen Fehler habe ich inzwischen auch gefunden:

Ich hatte (anders als im Beispiel oben) die Funktion wie folgt deklariert, da die Werte im übergebenen Feld geändert werden sollen:

[TimesChange]

So, einen hab' ich noch

Ich habe ein Array aus Strings fester Länge. Wenn ich dieses an eine SUB übergeben will bekomme ich untenstehende Fehlermeldungen.
What's wrong?

[nemored]

Zunächst einmal ist die Angabe von BYREF bei Arrays nicht erlaubt, da Arrays immer BYREF übergeben werden und BYVAL gar nicht möglich wäre.

Strings fester Länge können wohl grundsätzlich nicht als Parameter gefordert werden. Man kann einen String fester Länge angeben, wenn ein String variabler Länge gefordert ist - dieser wird dann automatisch umgewandelt. Bei String-Arrays geht das allerdings nicht.

Man würde da wohl üblicherweise mit ZSTRING PTR der STRING PTR arbeiten. Mit UDTs kann man auch etwas tricksen (auch wenn ich nicht weiß, ob meines die beste mögliche Lösung ist):

[TimesChange]

Ja, mit BYREF habe ich einen Bock geschossen, da wir das mit Arrays ja gerade erst beim Beispiel weiter oben hatten.
Ich habe mich da von der Hilfsdatei verwirren lassen:

[grindstone]

@TimesChange: Du könntest die fraglichen Variablen ja auch mit Dim Shared... als globale Variablen deklarieren. Dann kannst du wie einst bei GOSUB ohne Parameterübergabe von jedem Unterprogramm aus uneingeschränkt darauf zugreifen.

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

[TimesChange]

@grindstone: Ja, DIM SHARED würde das Problem auch lösen.
Das fände ich aber nicht so "elegant", da es hier nur um temporäre "Hilfsvariablen" geht, die nur kurzfristig innerhalb einer Sub benötigt werden.
In diesem speziellen Fall werde ich vermutlich sogar ganz darauf verzichten, den ehemaligen GOSUB-Block in eine Sub auszulagern, da er nur von 2 oder 3 Stellen innerhalb der Routine aufgerufen wird, und nur wenige Zeilen lang ist. Da erscheint es mir vertretbar, dieselben paar Zeilen an 2 oder 3 Stellen im Programm einzufügen.
Was anderes wäre es, wenn diese Subroutine umfangreicher wäre, oder von mehr Stellen aus aufgerufen werden würde.


Grüße
Rainer


P.S. @all: Ich hoffe, dass ich (hier und in meinen anderen Fragen) nicht undankbar wirke, wenn mir manche Vorschläge nicht "passen".
Ohne den hilfreichen Input hier aus dem Forum hätte ich's schon aufgegeben...

[grindstone]

Du kannst globale und lokale Variablen je nach Bedarf beliebig kombinieren. Das ist nicht unelegant, sondern äußerst praktisch und macht die Programmierung sehr flexibel.

Wenn du einige wenige Programmzeilen hast, die an mehreren Stellen identisch auftauchen, kannst du sie auch als Makro definieren und wie einen Unterprogrammaufruf an den entsprechenden Stellen platzieren. Der Kompiler fügt die Programmzeilen dann so ein, als wenn du sie dort explizit hingeschrieben hättest. Etwas störend ist nur, daß ein Makro vor seinem ersten Aufruf definiert werden muß. So etwas wie Declare gibt es für Makros nicht.

[nemored]

Es wäre noch zu überlegen, ob statt eines Strings fester Länge einer mit variabler Länge reichen würde. Ggf. kann er ja mit LEFT gekürzt werden. Die Feldlänge müsstest du übrigens gar nicht übergeben, LBOUND und UBOUND wird bei der Übergabe mitgeliefert. Außer du willst nicht das ganze Feld verwenden.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[TimesChange]

Jetzt hänge ich nochmal eine aktuelle Frage hier dran, da wir eh schon über Fixed Strings als Parameter gesprochen haben.

Grundsätzlich kann ich ja auch einen String fester Länge an eine Sub/Function übergeben, die einen STRING erwartet.
Zu meiner Überraschung funktioniert das in folgendem Beispiel auch, wenn der String ein 0-Byte enthält:

[HorstD]

[grindstone]

Ich bin auch erstaunt. Offenbar ist es nicht erlaubt, einen String mit fester Länge als Parameter an eine Function zu übergeben. In der Befehlsreferenz habe ich dazu nichts gefunden. Mit einem String ohne Längenfestlegung arbeitet das Programm korrekt.

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

[Sebastian]

Hallo,

wenn man entweder ZString als Argumenttyp verwendet oder den String BYVAL übergibt, wird die Variable immerhin durch den Funktionsaufruf nicht beschädigt. Ich glaube, mich dunkel zu erinnern, dass FB intern für Strings fester Länge ZString benutzt.
Allerdings kommt auch dann in der Funktion nicht der richtige Wert an, weil ja bei 0 terminiert wird und die "Binärzeichenkette" mit einem Nullbyte anfängt.

Generell muss man aber sagen, dass solche Binär-Rohdaten-Umwandlungen von Typ (Integer, Double, ...) zu String in FreeBASIC vollkommen überflüssig sind. Das macht eigentlich keiner mehr. Wozu sollte man die 4 Bytes eines Integers o. ä. erst in einen 4 Byte langen String packen, wenn man mit dem Integer direkt alles machen kann?

Man kann z. B. einen Pointer, der eigentlich auf einen Integer zeigt, auch mit CAST als Pointer auf einen Float "umdeuten" und dann so den Integer-Rohinhalt als Gleitkommazahl interpretieren lassen. Mir fällt spontan nichts in FB ein, wofür man mit MKI / CVI und Konsorten String-Operationen auf Binärdaten machen müsste (Rückwärtskompatibilität zu alten QB-Programmen von "anno dazumal" einmal ausgenommen).

Stattdessen kann man sich z. B. mit (C)ALLOCATE Speicherblöcke beliebiger Länge erstellen lassen. Oder man kann ein UBYTE()-Array verwenden. Dann hat man auch gleich Zugriff auf die einzelnen Bytes und muss sie nicht mit MID(...) aus einem n Byte langen String raussuchen.
Die primitiven Datentypen kann man in FB auch direkt in Dateien schreiben und auslesen (Dateimodus BINARY). Also man muss einen Integer nicht erst in einen 4-Byte-Binärstring verwandeln, um ihn als 4-Byte-Datum in eine Datei zu schreiben (statt als Dezimalrepräsentation variabler Länge).

Vielleicht kannst du den Anwendungsfall konkret beschreiben. Dann finden sich vielleicht bessere Lösungen als diese String-Umwandlungen. Die Rohdaten, z. B. eines Integers oder einer Gleitkommazahl, erst nach String umzuwandeln, um dann etwas damit zu tun, ist in FB einfach überflüssig geworden. In FB hat man auf jedes Byte direkten Zugriff, ohne solche Umwege ("von hier aus über Oslo nach Rom reisen") einbauen zu müssen, die auch noch für Fehler sorgen können.

Du kannst ja mal dieses Beispiel hier testen:

[nemored]