TimesChange
Anmeldungsdatum: 20.11.2013 Beiträge: 85
|
Verfasst am: 17.01.2014, 23:45 Titel: Erfahrungen bei Umsetzung von QB zu FB |
|
|
Ich habe gerade zwei Programme von QuickBasic (4.5) zu FreeBasic umgesetzt habe, was mich - trotz unverzichtbarer Unterstützung aus dem Forum - stellenweise ziemlich Nerven gekostet hat.
Daher ein paar Hinweise zu speziellen Punkten für Leute, die ähnlich wenig Programmiererfahrung haben wie ich (und wenn dann aus „alten’ Zeiten), und ebenfalls ein altes Programm portieren wollen.
Auf den ersten Blick sieht FreeBasic ja so aus, als würden ein QB-Programm 1:1 laufen. In sehr viele Bereichen ist das auch so, aber es gibt doch immer wieder teils deutliche Unterschiede. In der Freebasic-Referent ist zu jedem Schlüsselwort der Unterschied zu QB genannt, das ist schon mal recht hilfreich.
Am geringsten ist der Aufwand bei der Portierung, wenn man den Dialekt ‘-lang qb’ verwendet.
Die Probleme bei der Stringbehandlung durch FreeBasic (s.u.) hat man aber auch hier.
Will man den Standarddialekt ”lang fb” verwenden, müssen viele Befehle (wie Mid$ -> Mid) und Variablenbezeichnungen (mit Suffix wie „Zeichen$”) angepasst werden, was noch relativ schnell geht.
Außerdem sind Variablen generell mit DIM ... vor Verwendung zu deklarieren, was immerhin die Verständlichkeit des Quellcodes verbessert.
Sachen wie DEFINT, DEFDBL etc. gehen hier nicht mehr.
Etwas mehr Handarbeit erfordert es, die Parameter bei Übergabe an Subs und Funktionen zu überprüfen. Zum einen müssen auch diese jeweils mit „... AS Datentyp” genau beschrieben werden. Vor allem aber wurden Parameter in QB generell mit BYREF übergeben, während in Freebasic BYVAL Standard ist (außer bei Strings). Wenn also eine Veränderung der Parameter erwünscht ist, müssen diese ausdrücklich mit BYERF übergeben werden.
Kleines Beispiel: Eine Sub soll aus einem Datum in Textform „MM-TT-JJJJ” die Zahlenwerte für Tag, Monat und Jahr zurückliefern. Das klappt nur, wenn jeweils BYREF vor den Parameter eingefügt wird:
Code: | DIM as Integer JJ, MM, TT
Sub Datum (DS as String, ByRef J as integer, ByRef M as integer, ByRef T as Integer)
M = Val(Left(DS,2))
T = Val(Mid(DS,4,2))
J = Val(Right(DS, 4))
End Sub
Datum ( Date, JJ, MM, TT)
? "Tag : " ; TT
? "Monat:" ; MM
? "Jahr: " ; JJ
sleep
End |
Lasse ich hier (wie in QB) das BYREF weg, wird jeweils 0 ausgegeben.
Komplizierter wird es, wenn man ein Programm hat, das viel mit Strings arbeitet, und eventuell noch Strings in Dateien speichert / aus Dateien liest.
FreeBasic hängt an das Ende eine jeden (normalen) Strings noch ein 0-Byte an. Wenn ich also in QB 3 Strings mit je 4 Byte hintereinander in eine Datei schreibe, hat die Datei 12 Byte. In FB sind es 3 x (4+1) also 15 Byte. Hier muss man aufpassen.
Richtig unangenehm wird es, wenn man viele (!) Strings fester Länge verwendet hat. Insbesondere, wenn die Strings nicht nur „echten” Text enthalten, sondern irgendwelche Daten, so dass auch 0-Bytes vorkommen können.
In diesem Fall würde ich mir gut überlegen, mit gleich ein anderes Datenkonzept zu überlegen, statt mit Strings fester Länge zu arbeiten.
FB „schneidet” nämlich String fester Länge ab der Stelle des 0-Bytes ab. Wenn ich also an einen FixedString mit 4 Bytes, der im zweiten Byte den Wert „0" stehen hat, einen weiteren 4-Byte-String anhänge, bekomme ich keinen 8-Byte String, sondern nur einen 5-Byte String.
Ganz großartig ist es auch, wenn man in QB mit Datenkonvertierung mittels MKI$, MKD$ etc. gearbeitet hat. Abgesehen von der unterschiedlichen Länge eines Integers in QB (16 bit) und FB (32 bit) mag FB auch hier keine 0-Bytes, die hier zwangsläufig vorkommen können, zumindest wenn man diese Daten naheliegenderweise in Strings mit einer festen Länge gespeichert hat.
Übergibt man nämlich einen solchen Wert als Parameter an eine Sub oder Function, wird der ursprüngliche Wert ab dem 1. Byte mit Wert 0 auf Null gesetzt...
Auch wenn man - wie in QB problemlos möglich - als z.B. MKL$ gespeichert Werte in der Größe vergleichen will, kann man lustige Überraschungen erleben.
Bitte davon nicht entmutigen lassen, man kann mit FreeBasic viel mehr machen als mit QuickBasic. Und mancher „Umweg”, wie das Speichern von Zahlenwerten nach Umwandlung mittels MKL$ etc., ist in FreeBasic gar nicht mehr nötig.
Hätte ich vorher geahnt, dass Strings fester Länge in FreeBasic solche Probleme bereiten, hätte ich mir gleich etwas anderes überlegt, und mir viel Arbeit erspart.
Ich hoffe, meine Erfahrungen beim Umsetzen können dem ein oder anderen mal nützlich sein.
Viele Grüße
Rainer |
|