Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Erfahrungen bei Umsetzung von QB zu FB

 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC.
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
TimesChange



Anmeldungsdatum: 20.11.2013
Beiträge: 85

BeitragVerfasst am: 17.01.2014, 23:45    Titel: Erfahrungen bei Umsetzung von QB zu FB Antworten mit Zitat

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
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC. Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz