Seite 5 von 5
Verfasst: 29.01.2006 14:28
von remi_meier
Habs bis jetzt auch nicht verstanden
. Aber ev. meint er, dass es zu
Problemen kommen kann bei z. B. (Pseudocode):
Code: Alles auswählen
Struct test
s.s
s1.s
endstruct
*p.test = allocmem(sizeof(test))
*p\s = "lala"
*p\s1 = "dada"
FreeStructuredStrings(*p, ?...)
; da der Speicher für die Struktur noch allociert ist, können wir ihn weiter
; benutzen:
*p\s = "dodo" ; !!! hier könnte AFAIK wirklich ein Problem auftreten, da
; meines Wissens nach FreeStructuredStrings() nach den Pointern in der
; Struktur geht und nicht nach intern gespeicherten! Somit würde versucht,
; ein Speicher freizugeben, der schon frei ist ähnlich:
; *p = AllocateMemory(20)
; FreeMemory(*p)
; FreeMemory(*p)
; Ich denke aber nicht, dass das ein Problem sein kann, denn so macht
; es gar keinen Sinn FreeStructuredStrings() auszuführen und nebenbei
; scheint das Freeen von schon gegfreeten Speichern kein Problem dar-
; zustellen.
Wenn das nicht das Problem ist, dann schreib doch bitte nochmals inkl.
Pseudocode
greetz
Remi
Verfasst: 29.01.2006 19:53
von Toshy
@remi_meier
Ziehmlich genau so ist es gemeint, da wo du denkst, das ein Problem entstehen könnte, denke ich das auch.
Und es könnte bzw. wird zwischen "freememroy" und "freestructurestrings" ein unterschied bestehen. bei "freememory" weiß pb ja was freigeben ist und bei "freestuctruestrings" nicht, ist ja eine Userroutine. Es kommt also darauf an was intern geschieht, und das ist da Problem.
Es kann aber sehr wohl sinnvoll sein die Struktur so in der Art zu nutzen. Dieses Beispiel ist natürlich wirklich für ein Programm ohne großen sinn.
Ich selbst muß große Datenbereiche mit Strukturen füllen und dann einzelne Strukturelemente rausnehmen oder welche hinzufügen.
Arrays gehen aus unterschiedlichen gründen nicht, also "Memory".
Um das nun hinzubekommen lagere ich temporär den Memorybereich aus (einfach kopieren, manchmal n ur einen Teil) und kopiere ihn zurück OHNE die zu entferende Struktur bzw. mit einer zusätzlichen.
Um Geschwindigkeit zu sparen erstelle ich dabei den Memorybereich nicht immer vollkommen neu. Und dadurch kommt es halt sehr oft dazu das schon Daten im Speicher ist der von einer Struktur überschrieben wird.
Daher ist interessant und wichtig zu wissen, wie PB nun wirklich intern arbeitet um solche Fehler auszuschließen und trotzdem das Optimum an Geschwindigkeit zu erhalten.
Aber (leider) bin ich wenigstens in der Befürchtung bestätig worden, daß es hier schon einen Fehler geben kann. Darauf hat bisher wohl kaum einer geachtet, einfach weil es nur bei wenigen Programmstrukturen auftreten kann.
Ich muß und will halt sauber programmieren, recht optimal wenn es auch nicht geht. War schon immer etwas pingelig damit, dafür gibt es bei mir auch so gut wie nie Abstürzte.
Mein Problem ist also so wie du bemerkt hast rauszufinden ob hier wirklich ein Problem auftreten kann. Rauszufinden (fast) nur mit Kenntnissen der PB Internas.
Gruß
Thorsten
Verfasst: 29.01.2006 23:16
von helpy
Hi Friedrichs,
OK! Warum überhaupt in einer Struktur mit "FreeStructureStrings" die Strings freigeben, wenn die Struktur doch wieder verwendet wird? Was für einen Sinn hat das? Wenn in diesem Fall die Struktur initialisiert werden soll, dann musst Du das ja sowieso in Deinem Programm machen (einzelne Variablen auf "0" setzen und den Strings würde ich dann einen Leer-String zuweisen).
"FreeStructureStrings" ist doch wirklich nur dann aufzurufen, wenn der Speicher der zugehörigen Struktur freigegeben wird.
cu, helpy
Verfasst: 22.03.2006 17:40
von helpy
Hi,
Here "
FreeStructureStrings as normal PB FUNCTION/COMMAND" you find a littel Macro, which you can use to free StructuredStrings. With this macro you do not need to declare/define the data offsets in PureBasic.
[Nachtrag]...
)
Jetzt passiert mir das doch umgekehrt ... man sollte nicht so viel zwischen den beiden Foren hin und her wechseln.
Also hier in deutsch:
Hier "
FreeStructureStrings as normal PB FUNCTION/COMMAND" findet Ihr ein kleines Makro, das man verwenden kann, um Strings in dynamischen Strukturen freizugeben. Mit diesem Makro muss man nicht einmal die Offsets der String-Elemente innerhalb der Strukturen in den PB-Code eingeben. Dafür werden die vom PBCompiler erzeugten Offset-Tabellen verwendet.
cu, helpy
Verfasst: 27.12.2006 17:13
von Hellhound66
Wenn man Strings ganz einfach als das Handlen würde, als das was sie sind, nämlich Zeiger, dann hätten wir das Problem nicht. Ich nutze Strings nur noch zur Debugausgabe, ansonsten versuch ich die Dinger zu vermeiden.
Was mich auch stört ist:
String.s = @string.s
Ich dachte @ wäre ein Referenzierungszeichen, aber das war man hier wohl inkonsequent.