Seite 2 von 4
Verfasst: 04.07.2006 18:12
von MVXA
Nö... Warum kritisiert ihr alle meine geniale Lösung? Seid ihr neidisch
oder wie darf ich das vestehen?
Verfasst: 04.07.2006 18:14
von #NULL
Code: Alles auswählen
Macro tex_name(Index)
PeekS(?tex_name_img+(Index*4))
EndMacro
Debug tex_name(0)
Debug tex_name(1)
Debug tex_name(2)
Debug tex_name(3)
Debug tex_name(4)
Debug tex_name(5)
DataSection
tex_name_img:
Data.s "so", "mat", "man", "das", "in", "PureBasic"
EndDataSection
output:
Verfasst: 04.07.2006 18:17
von #NULL
an der adresse des labels liegen keine pointer zu null-terminierten strings. sondern dort liegen die strings selbst, und die brauchen jeweils so viel bytes wie sie zeichen haben, und noch eins mehr zum terminieren.(oder?)
Verfasst: 04.07.2006 18:30
von MVXA
//Edit:
Öhm, moment mal. Das scheint ein Fehler von PureBasic zu sein.
Code: Alles auswählen
Macro tex_name(Index)
PeekS(?tex_name_img+(Index*4))
EndMacro
Debug tex_name(0)
Debug tex_name(5)
DataSection
tex_name_img:
Data.s "so", "macht", "man", "das", "in", "PureBasic"
EndDataSection
Funktioniert ohne Probleme. Dein Code macht bei mir aber den selben Mist...
Verfasst: 04.07.2006 18:36
von #NULL
das ist zufall, weil der 0-char vor "PureBasic" bei 20 liegt, also einem vielfachen von 4 (sorry bei mir waren die strings etwas anders)
in wirklichkeit liegen die daten so vor:
so0macht0man0das0in0PureBasic0
...wenn du jetzt bei einem vielfachen von vier irgendwo einsteigst, landet er in einem beliebigen string und liest weiter bis zum ersten auftauchenden 0-char.
Verfasst: 04.07.2006 18:45
von MVXA
stimmt.... das hab ich jetzt erst getestet. Dann ist das eher ne Limitation.
Aber einfach ein @ vor die Strings setzen und dann Data.l drauß machen
geht auch nicht, dann kommt es zu einem "assembler" fehler...
Code: Alles auswählen
---------------------------
PureBasic - Assembler error
---------------------------
PureBasic.asm [372]:
dd "so",0,"macht",0,"man",0,"das",0,"in",0,"PureBasic",0
error: value out of range.
---------------------------
OK
---------------------------
Verfasst: 04.07.2006 18:49
von ts-soft
>>Öhm, moment mal. Das scheint ein Fehler von PureBasic zu sein.
Ist auch falsch, aber von Dir, müßte so aussehen:
Code: Alles auswählen
Procedure.s tex_name(Index)
Restore tex_name_img
For I = 1 To Index + 1
Read Text.s
Next
ProcedureReturn Text
EndProcedure
For I = 0 To 5
Debug tex_name(I)
Next
DataSection
tex_name_img:
Data.s "so", "macht", "man", "das", "in", "PureBasic"
EndDataSection
Da finde ich mein Macro schöner
Verfasst: 04.07.2006 20:32
von real
Oh Gott, nein Danke! Dann mach ich's lieber in C, wenn ich in PB nichtmal solch ein dämliches Array vordefinieren kann.
Wieder mal ein Beispiel, dass PB nicht universell einsetzbar (und praktikabel) ist.
Trotzdem vielen Dank für Eure Unterstützung!
Verfasst: 04.07.2006 20:39
von ts-soft
real hat geschrieben:Oh Gott, nein Danke! Dann mach ich's lieber in C, wenn ich in PB nichtmal solch ein dämliches Array vordefinieren kann.
Wieso, Kaeru hats doch gezeigt, der Rest sind ja nur alternativen
real hat geschrieben:
Wieder mal ein Beispiel, dass PB nicht universell einsetzbar (und praktikabel) ist.
Das gilt aber nur für unflexible Programmierer!
Verfasst: 04.07.2006 21:31
von Kaeru Gaman
außerdem
Kaeru Gaman hat geschrieben:in PB musst du die werte aus DATA oder einer Datei einlesen, sofern du sie nicht direkt hinschreiben willst
das einlesen aus einer data-section ist praktisch das selbe.
AUSSERDEM ist das was du in C machst auch nur das erzeugen eines pointers direkt auf deine im code angegebenen daten, also effektiv DASSELBE wie eine eingeschlossene DATA-section in PB, mit dem unterschied, dass man sie in PB nur deshalb nicht diirekt als String-Array nutzen kann, weil ein String-Array in PB eben nicht die strings sondern die pointer zu ihnen enthält.
ts-soft hat geschrieben:Das gilt aber nur für unflexible Programmierer!
dem schließe ich mich an. über PB zu meckern, nur weil ein ausgesprochen C-spezifisches Konstrukt keine direkte entsprechung hat, das ist ja *******