Object destroyen

Klassen, Objekte, Methoden, Instanzen

Moderator: Moderatoren

Re: Object destroyen

Beitragvon Jan » Mi, 14. Nov 2012 14:09

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. :badgrin:


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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Foren-Administrator
Foren-Administrator
 
Beiträge: 11765
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle

Re: Object destroyen

Beitragvon brandelh » Mi, 14. Nov 2012 14:20

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()) .
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13384
Registriert: Mo, 23. Jan 2006 21:54
Wohnort: Germersheim

Re: Object destroyen

Beitragvon Manfred » Do, 15. Nov 2012 18:42

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.
Gruß Manfred
Mitglied der XUG Leverkusen
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
Benutzeravatar
Manfred
Foren-Moderator
Foren-Moderator
 
Beiträge: 16238
Registriert: Di, 29. Nov 2005 17:58
Wohnort: Kreis Wesel

Re: Object destroyen

Beitragvon Martin Altmann » Do, 15. Nov 2012 19:14

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 :wink:

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: http://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: http://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
 
Beiträge: 12964
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin

Re: Object destroyen

Beitragvon Manfred » Do, 15. Nov 2012 19:16

Du hast aber schon verstanden, woher diese Aussage stammt?
Gruß Manfred
Mitglied der XUG Leverkusen
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
Benutzeravatar
Manfred
Foren-Moderator
Foren-Moderator
 
Beiträge: 16238
Registriert: Di, 29. Nov 2005 17:58
Wohnort: Kreis Wesel

Re: Object destroyen

Beitragvon Martin Altmann » Do, 15. Nov 2012 19:21

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
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: http://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: http://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
 
Beiträge: 12964
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin

Re: Object destroyen

Beitragvon Manfred » Do, 15. Nov 2012 19:24

=D>
Gruß Manfred
Mitglied der XUG Leverkusen
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
Benutzeravatar
Manfred
Foren-Moderator
Foren-Moderator
 
Beiträge: 16238
Registriert: Di, 29. Nov 2005 17:58
Wohnort: Kreis Wesel

Re: Object destroyen

Beitragvon brandelh » Do, 15. Nov 2012 21:27

Martin Altmann hat geschrieben:Nein - wie sollte ich das anhand Deines einen Satzes verstehen?


indem man liest was in dem Thread schon besprochen wurde. ;-)
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13384
Registriert: Mo, 23. Jan 2006 21:54
Wohnort: Germersheim

Re: Object destroyen

Beitragvon AUGE_OHR » Fr, 16. Nov 2012 8:02

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 ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10279
Registriert: Do, 16. Mär 2006 8:55
Wohnort: Hamburg

Vorherige

Zurück zu OOP

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast