Seite 2 von 2
Re: Object destroyen
Verfasst: Mi, 14. Nov 2012 13:09
von Jan
Tom hat geschrieben:Ich erinnere mich, dass SP beim Forentreffen oder bei der DevCon zugesagt hatte, Alaska wolle gelegentlich ins Forum schauen, um dann via Verein bei Threads zu intervenieren (also eine Klarstellung zu liefern), die inhaltlich aus dem Ruder laufen. Ich denke, dieser Thread wäre eine gute Gelegenheit, um diese Vorgehensweise mal auszuprobieren.
Tom,
das habe ich bei zwei Gelegenheiten schon gemacht. Einmal auf einen Thread hier hingewiesen - null Reaktion. Eine Problemstellung aus dem Forum an Alaska gesendet - niemals eine Antwort darauf erhalten außer, das man dabei sei, das zu beantworten. Nur kam diese Antwort niemals an.
Soweit zu der Vereinbarung, die der Verein mit Alaska geschlossen hat. Ich selber werde die nicht wieder einfordern. Lächerlich machen kann ich mich auch auf nettere Weise.
Jan
Re: Object destroyen
Verfasst: Mi, 14. Nov 2012 13:20
von brandelh
Tom hat geschrieben:cX ist zwar LOCAL und wird als solche auch entsorgt, ist aber tatsächlich ja nur ein Zeiger auf den ASCIIZ String, der zugewiesen wurde.
Wer erzählt denn so was?
Weil Xbase++ intern (wie viele andere auch) Stringvariablen auf STACK und HEAP aufteilen.
Lokale numerische Variablen landen auf dem STACK und brauchen entweder 32Bit (LONG, 4Byte) oder 64Bit (DOUBLE, 8 Byte).
Also genau einen definierten Wert und dort werden diese auch gespeichert (auf dem STACK).
Bei einem String kann aber sehr viel gespeichert werden, auch wenn wir heute mehr STACK haben (einstellen können), wäre der richtige Text (z.B. 200 MB) viel zu groß für den Stack.
Daher werden Stringvariablen getrennt gespeichert. Der POINTER auf dem Stack (32 Bit) und der Rest auf dem Heap, allerdings als Byte Array, sonst könnten wir keine chr(0) im String speichern.
Insoweit war ich nicht ganz exakt mit meiner Aussage, Xbase++ übergibt als Parameter seine Strings als ASCIIZ String an DLLs (DLLCALL()) .
Re: Object destroyen
Verfasst: Do, 15. Nov 2012 17:42
von Manfred
Ein Xbase++ Objekt liegt in der Hoheit des GC. Wenn keine Referenz auf das Objekt existiert, wird es weggeräumt.
Stell dir das so vor, wie ein Array. Hier musst du auch nicht alle Elemente einzeln NILen.
Re: Object destroyen
Verfasst: Do, 15. Nov 2012 18:14
von Martin Altmann
Unsinn.
Bei folgendem Konstrukt (sinngemäß) müssen die einzelnen Arrayelemente aufgeräumt (:destroyed()) werden:
Code: Alles auswählen
aAdd( aPublic, ::XbpDialog():new( AppDesktop(), SetAppWindow(), {0,0}, {555,600}, , .F.) )
Merke:
Pauschalaussagen sind gefährlich
Viele Grüße,
Martin
Re: Object destroyen
Verfasst: Do, 15. Nov 2012 18:16
von Manfred
Du hast aber schon verstanden, woher diese Aussage stammt?
Re: Object destroyen
Verfasst: Do, 15. Nov 2012 18:21
von Martin Altmann
Nein - wie sollte ich das anhand Deines einen Satzes verstehen?
Aber ich vermute mal, von Alaska. Ist aber trotzdem Mumpitz (s. mein Beispiel). Und wenn Dir das so nicht "passt", nimm halt ein anderes (nicht-Alaska) Objekt!
Viele Grüße,
Martin
Re: Object destroyen
Verfasst: Do, 15. Nov 2012 18:24
von Manfred
=D>
Re: Object destroyen
Verfasst: Do, 15. Nov 2012 20:27
von brandelh
Martin Altmann hat geschrieben:Nein - wie sollte ich das anhand Deines einen Satzes verstehen?
indem man liest was in dem Thread schon besprochen wurde.
Re: Object destroyen
Verfasst: Fr, 16. Nov 2012 7:02
von AUGE_OHR
brandelh hat geschrieben:Sobald die EXE beendet wird, wird von der Runtime schon dafür gesorgt, dass alles (Speicher und Resourcen) wieder freigegeben werden.
wenn man nicht schon per Dllcall oder activeX oder auch Ownerdraw alles "durcheinander" gebracht hat
der Kern der Frage von Manfred ist ja mit Thread verknüpft den "da" liegt" IMHO immer noch das Problem.
Manfred sagt ja das er durch das NILlen der LOKAL etwas erreicht hat ... und ich hab in meinen WMPlayer STATIC (!!!) stehen.
es geht "speziell" um Threads mit o:setInterval() / o:setStartTime() wo man wirklich mal eine STATIC ausprobieren sollte ...
auch der "komische" Tip mit PRIVAT (in Main) statt PUBLIC hat mit besagten Threads zu tun die man "auf einmal" nicht mehr in der Errorsys "sieht".
beachte das ausser "deinen" Threads ja auch noch die "internen" Threads
new thread=2
GC=3
timer=4
EVM=5
genügend Zeit erhalten und nicht durch "deine" Thread "blockiert" werden
was den CG angeht : SLEEP(0) hilft viel und koste nix
p.s. kannst du aus den Threads nicht "einzelne" Applicationen machen ?