Garbage Collector für Delphi-Objekte?

[himitsu]

Weißt du wie oft, vorallem bei Fremdkomponenten und auch bei Emba selber, Objekte in z.B. irgendwelchen "Integern" oder Pointern gespeichert werden?
Da wird nichts gezählt und schon knallt's schnell mal.

Free gibt es zwar immernoch, aber Free gibt nun nichts mehr "direkt" frei.
Und bei Kreuzreferenzen muß man dann auch noch extrem aufpassen, da sie sich selber im Speicher halten können, vorallem da sie nicht mehr auf Free hören.

[BUG]

Ich kann mir vorstellen, dass sich die Integration in Systeme mit GC wesentlich besserer macht, wenn man selbst irgendeine Art von GC hat.
Wenn man allerdings schon etwas wie die RTTI hat, fände ich es merkwürdig, sich gerade Reference-Counting auszusuchen.

[jaenicke]

Ich denke da speziell an Windows RT...
Das habe ich zwar noch nicht gesehen, aber ich vermute mal ein GC ist da hilfreich.

[BUG]

Zitat von jaenicke:

Ich denke da speziell an Windows RT...

Fast alle neueren Plattformen haben einen GC (imho mit Recht).
Android (Java), WinRT (.net), Browser (HTML5+JavaScript) ... oh, sieh an, in Objective-C werden auch fleißig Referenzen gezählt

[himitsu]

Dann wäre ja delphi irgendwann so wie dieses komische C#

Nja, und dafür wären dann auch viele Codes vor und nach diesem halben GC praktisch nicht mehr kompatibel.

[Medium]

Wieso? Einfach .Free() seiner Funktion berauben (was im Compiler prima geht), alles was manuell mit SPeicher rum macht ist auch sicher, da GetMem/FreeMem New/Dispose wohl nicht angefasst werden, und ich kann mir im Moment nichts vorstellen was man sinnvoll anderes an Konstrukten mit gutem Gewissen gebaut haben könnte. Selbst wenn: Es wäre ein Hack, und würde "mit Recht" kaputt gehen, zumindest aber nicht unerwartet (wenn man einigermaßen sauber zu Werke ging). Es ist ja jetzt nicht neu, dass Hacks nach Versionsänderungen (oder sogar schon Patches) dahin sein können. Das nimmt man wissentlich in Kauf wenn man anfängt zu frickeln. (Tu ich ja auch ab und an, aber ich bin dann nicht knüsselig wenn es mal nicht mehr geht oder geändert werden muss.)

[himitsu]

Nja, im Prizip greifen dann in etwa die selben Mechianismen bei Objekten, wie sie schon für Interfaces gelten.


Mal im Ernst, wir haben doch Interfaces und Objekte.
Wenn man das Verhalten eines Interfaces will, dann sollte man Dieses doch auch verwenden?
(bekommt man den schweren Anhänger nicht weg, dann spannt man einen Traktor davor und nicht den Ferrari)

Ich freu mich schon auf die Verknubbelung der verschiedenen Techniken.
TComponent+Owner, Interfaces mit und ohne Referenzzählung, das Free/Destroy der Objekte und dann noch das Neue.

Außerdem, wenn schon Garbage Collector, dann doch gleich richtig?
Hier ist es scheinbar ausschließlich für Objekt-Instanzen vorgesehn.
Also die neue Funktion ... Interfaces, dynamische Arrays, LongStrings und Variant mal außer Acht gelassen, woran sich seit Jahrzehnten, praktisch schon fast immer, nichts dran geändert hat.



Ach ja, es geht übrigens um den Compilerschalter {$IFDEF AUTOREFCOUNT}
[WARUMHABENWIRKEINENSPOILERODERSO]
Der sich eventuell duch einen Parserfehler(?) schon massenhaft in der OH eingenistet hat.

Zitat von Wie ich dieses Parsermistding hasse -.-:

Embarcadero Technologies verfügt zurzeit über keine zusätzlichen Informationen. Bitte unterstützen Sie uns bei der Dokumentation dieses Themas, indem Sie Ihre Kommentare auf der Diskussionsseite eingeben.

[/WARUMHABENWIRKEINENSPOILERODERSO]
und vermutlich das Attribut [Weak] synopse - Delphi XE3 is preparing reference counting for class instances
Roman's Blog




Einfache Beispiele, welche bestimmt an vielen Stellen Probleme bereiten könnten werden, wären z.B. die TList und alles Andere, wo "Objekte" in einem Data-"Pointer" hinterlegt werden.
Oder Objekte per Messages verschicken. (programmintern natürlich)

In Delphi werden bis jetzt problemlos Objekte ständig umhergecastet (OK, bei Win64 nicht ganz unproblematisch, aber da sind die Programmierer ja praktisch obftmals selber dran Schuld)
und genau an diesen Stellen muß es doch zangsläufig die Referenzzählung falsch zählen.




Kreuzreferenzen werden eventuell auch Spaß bereiten.
- ObjektB kennt ObjektA (in einem Feld gespeichert)
- ObjektA kennt und verwaltet ObjektB (in einem Feld gespeichert)
- im Destructor von A wird B freigegeben

Da hier aber eine Referenz von A in B drinsteckt, wird nichmal mehr beim A.Free der Destructor aufgerufen, da es ja noch eine weitere Referenz gibt.
Wie/Ob die es machen, daß beim Freigeben von A die Referenz in B automatisch auf nil gesetzt wird, würde ich gerne wissen (klingt aber so, als wenn die das eventuel machen wollen?)



Ganz im Ernst. Wie haben doch schon Interfaces ... warum verwendet man Diese nicht einfach, wenn man ihre Funktionalität z.B. für WinRT benötigt.
Ich hatte doch auch mal vorgeschlagen, daß man die Interfaceverwaltnug/-erstellung für sowas hätte vereinfachen können.

Im Compiler eine Funktion/Befehl, welcher aus den Public-Schnittstellen eines Objektes "automatisch" ein Interface erstellt.

z.B.:

Delphi-Quellcode:

type
  TMyObject = class(TInterfacedObject)
  public
    function Irgendwas: Integer;
  end as IMyInterface['{6C68C66B-ED43-42D1-8BF2-B41327A31673}'];  // mit oder ohne GUID

IMyInterface sähe in diesem Fall dann intern so aus:

Delphi-Quellcode:

type
  IMyInterface = interface
    ['{6C68C66B-ED43-42D1-8BF2-B41327A31673}']
    function Irgendwas: Integer;
  end;

Wenn die keine Lust haben für ihre neue WinRT-API für jedes Objekt ein Interface zu erstellen, dann ginge das auch automatisch, ohne die Objekte selber verschandeln umbauen zu müssen.

[jaenicke]

Zitat von himitsu:

In Delphi werden bis jetzt problemlos Objekte ständig umhergecastet (OK, bei Win64 nicht ganz unproblematisch, aber da sind die Programmierer ja praktisch obftmals selber dran Schuld)
und genau an diesen Stellen muß es doch zangsläufig die Referenzzählung falsch zählen.

Diese Altlasten aus Zeiten vor Generics müssen dann eben erneut sauber implementiert werden.
Wer solchen Code heute mit einem aktuellen Delphi noch schreibt / schreiben lässt, ist selber schuld.