Wie Datenstrukturen in PB umsetzen
Verfasst: 06.12.2013 18:24
Hallo,
ich programmiere seit fast 30 Jahren, komme aber nun vom GFA Basic (ursprünglich mal Atari, dann bis heute Win-16-Bit, und weniges unter Win-32-Bit) neu zu PB, und brauche mal ein paar Tips bzw. habe ein paar Fragen, wie ich meinen bestehenden GFA-Code am besten in PB übersetze.
Da die alten GFA-Versionen recht problematisch waren, wenn es um Zeiger, Speicherbereiche, Strukturen etc. ging, es im Gegenzug unter GFA aber keine Probleme mit Strings gab, wenn diese CHR(0) enthielten, man also in Strings auch gut Word, Long etc. speichern konnte, und es im GFA tolle Funktionen zum entfernen einzelner Array-Elemente und einfügen von Array-Elementen an bestimmten Stellen im Array gab, habe ich dort zur Speicherung meiner Daten intensiv mit String-Arrays gerarbeitet, die mir quasi so etwas wie Strukturen nachgebildet haben, allerdings auch nicht so fix in der Länge waren, wie Strukturen.
Mir stellt sich nun die Frage, wie ich das folgende knapp gehaltene Beispiel sinnvoll in PB machen kann, um möglichst viel durch ein automatisches Code-Umschreibe-Tool zu erwischen und nicht zigtausend Codezeilen von Hand ändern zu müssen.
Z.B. habe ich ein String-Array in dem zwei unterschiedliche Datenarten abgelegt werden.
Die Struktur "kopf" ist soweit klar, in der Struktur "daten" sind in meiner bisherigen GFA-Konstruktion aber nur die ersten 4 Variablen "anz bis bva" fest, und abhängig vom Wert von "bva" folgen dann "apr und bvp" oder/und "ltx und txt". Soweit wäre das auch noch zu regeln, wenn ich einfach alle Variablen immer in der Struktur hätte und txt (das ist der einzige echte Text-String) auf eine feste Länge setzen würde. Es gäbe halt nur einen gewissen Overhead für die nicht immer gebrauchten Daten, was im Vergleich zu Anfang/Mitte der 90er, wo mein Code teilweise schon entstanden ist, bei heutigem Arbeitsspeicher kein Problem mehr wäre.
Schwieriger wird es nun, weil "anz" die Anzahl der von "anr bis ggfls. txt" folgenden Blöcke definiert, d.h. hinter dem ersten "txt" kann es in meinem GFA-String nun wieder neu losgehen mit Variablen ab "anr". Sicherlich wäre auch das mit deutlichem Overhead zu lösen, indem ich den Block "anr bis txt" in eine neue Struktur packe und diesen in "daten" wiederum als array einbaue.
Bleibt die ernsthafte Frage, ob das nicht irgendwie geschickter geht?
Eine Alternative und vermutlich schneller portierbar wäre mit Sicherheit, ein Array oder eine Liste nur mit Pointern auf einen je Zeile passend allozierten Speicherbereich aufzubauen. Dann könnte ich die für mein "im String speichern und da wieder rausholen" verwendeten GFA-Funktionen MKI$, MKL$ und CVI, CVL etc. einfach auf Speicherzugriff umschreiben.
Nur wie schnell und stabil ist PB dann, wenn man da einige 100 bis wenige 1000 kleine Speicherbereiche alloziert hat, und sich für jeden einzelnen den Pointer merken muß?
Ich hab zwar vor zig Jahren mal mit Pascal angefangen, auch mal C(++) gelernt, aber ich muß ehrlich sagen, daß mir damals die verketteten Listen, Pointer und der ganze Kram irgendwie nie so aufgegangen sind, ähnlich wie OOP nicht so mein Ding ist, auch wenn ich dadurch viele Dinge mit Sicherheit auf Umwegen lösen mußte.
Wie würde ein PB-Profi das lösen, lieber sauber mit Strukturen, oder mit Speicherbereichen?
So, fürs erste Posting ist das hier nun reichlich lang geworden, ich hoffe trotzdem auf Hilfe.
Im Voraus vielen Dank und vieleGrüße,
Jens
ich programmiere seit fast 30 Jahren, komme aber nun vom GFA Basic (ursprünglich mal Atari, dann bis heute Win-16-Bit, und weniges unter Win-32-Bit) neu zu PB, und brauche mal ein paar Tips bzw. habe ein paar Fragen, wie ich meinen bestehenden GFA-Code am besten in PB übersetze.
Da die alten GFA-Versionen recht problematisch waren, wenn es um Zeiger, Speicherbereiche, Strukturen etc. ging, es im Gegenzug unter GFA aber keine Probleme mit Strings gab, wenn diese CHR(0) enthielten, man also in Strings auch gut Word, Long etc. speichern konnte, und es im GFA tolle Funktionen zum entfernen einzelner Array-Elemente und einfügen von Array-Elementen an bestimmten Stellen im Array gab, habe ich dort zur Speicherung meiner Daten intensiv mit String-Arrays gerarbeitet, die mir quasi so etwas wie Strukturen nachgebildet haben, allerdings auch nicht so fix in der Länge waren, wie Strukturen.
Mir stellt sich nun die Frage, wie ich das folgende knapp gehaltene Beispiel sinnvoll in PB machen kann, um möglichst viel durch ein automatisches Code-Umschreibe-Tool zu erwischen und nicht zigtausend Codezeilen von Hand ändern zu müssen.
Z.B. habe ich ein String-Array in dem zwei unterschiedliche Datenarten abgelegt werden.
- Jedes Array-Element ist entweder eine Kopfzeile oder eine Datenzeile, die ersten beiden Bytes sind ein Word-Wert, der einfach den Typ der im selben Element nachfolgenden Daten definiert (0=Kopfzeile, 1=Datenzeile).
- Ein Kopfzeilen-Element enthält nach der Typfestlegung in den nächsten Bytes mehrere Byte, Word- oder Long-Werte, die einfach mit ihren jeweils 1, 2 oder 4 Byte Länge hintereinander in den String geschrieben werden, das Kopfzeilen-Element hat auch eine feste Länge
- Ein Datenzeilen-Element enthält nach der Typfestlegung dann in den nächsten Bytes völlig andere Byte, Word- oder Long-Werte, und ausgehend von diesen Werten hat es eine Mindestlänge an Informationen, die Länge kann aber auch basierend auf bereits weiter vorne stehenden Werten ansteigen, um weitere zugehörige Werte im selben Element unterzubringen
Code: Alles auswählen
Structure kopf
bnr.l
std.a
min.a
knr.u
EndStructure
Structure daten
anz.u
stk.u
anr.l
bva.u
apr.l
bvp.u
ltx.u
txt.s
EndStructure
Structure zeile
ein.w
StructureUnion
i.kopf
a.daten
EndStructureUnion
EndStructure
Schwieriger wird es nun, weil "anz" die Anzahl der von "anr bis ggfls. txt" folgenden Blöcke definiert, d.h. hinter dem ersten "txt" kann es in meinem GFA-String nun wieder neu losgehen mit Variablen ab "anr". Sicherlich wäre auch das mit deutlichem Overhead zu lösen, indem ich den Block "anr bis txt" in eine neue Struktur packe und diesen in "daten" wiederum als array einbaue.
Bleibt die ernsthafte Frage, ob das nicht irgendwie geschickter geht?
Eine Alternative und vermutlich schneller portierbar wäre mit Sicherheit, ein Array oder eine Liste nur mit Pointern auf einen je Zeile passend allozierten Speicherbereich aufzubauen. Dann könnte ich die für mein "im String speichern und da wieder rausholen" verwendeten GFA-Funktionen MKI$, MKL$ und CVI, CVL etc. einfach auf Speicherzugriff umschreiben.
Nur wie schnell und stabil ist PB dann, wenn man da einige 100 bis wenige 1000 kleine Speicherbereiche alloziert hat, und sich für jeden einzelnen den Pointer merken muß?
Ich hab zwar vor zig Jahren mal mit Pascal angefangen, auch mal C(++) gelernt, aber ich muß ehrlich sagen, daß mir damals die verketteten Listen, Pointer und der ganze Kram irgendwie nie so aufgegangen sind, ähnlich wie OOP nicht so mein Ding ist, auch wenn ich dadurch viele Dinge mit Sicherheit auf Umwegen lösen mußte.
Wie würde ein PB-Profi das lösen, lieber sauber mit Strukturen, oder mit Speicherbereichen?
So, fürs erste Posting ist das hier nun reichlich lang geworden, ich hoffe trotzdem auf Hilfe.
Im Voraus vielen Dank und vieleGrüße,
Jens
