Garbage Collector für Delphi-Objekte?

[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.)

[stahli]

Zitat von himitsu:

Jetzt (noch) nicht (unbedingt) nervig, aber vielleicht erstmal nur ein bissl erschreckend ... wem ist im XE3-Quellcode etwas aufgefallen?
Man versucht nun von hinten durch die Brust das TObjekt in ein eine Art Interface umzuwandeln und mit einer Referenzzählung zu versehn.
Eigentlich hatte ich nun endlich mal ein System für mehrfach gegenseitig kreuzreferenzierende Objekte, aber jetzt hab ich Angst, daß mir diese blöde Referenzzählung irgendwann alles wieder kaputt macht und ich wunderschöne "Speicherlöscher" erhalte.

Kann das mal jemand in einen eigenen Thread auslagern?
Was sind die genauen Konsequenzen?
Greifen die Änderungen auch bei einer klassischen Objekterzeugung - sprich: Das das Auswirkungen auf bestehende Projekte?

Ich habe zwar mal die Quelle angesehen, aber meine Brille ist wohl irgendwie nicht ganz scharf gestellt...

[himitsu]

Ich melde es gleich mal einen Mod ... muß nur noch schnell den Anfangsbeitrag raussuchen.
Wer dann antworten möchte, kann's da drüben machen (mach ich dann auch gleich)

[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.

[Stevie]

Klassischer Fall von "keinem kann mans recht machen".

Auf der einen Seite schreien genug Leute, dass man neue Features in die Sprache bringen soll und breaking changes in Kauf nehmen soll (wenn man das nicht will, muss man halt auf der letzten Version vor dieser Änderung bleiben, Pech) und auf der anderen Seite schreien die Leute, wenn dann was geändert wird für einen "nextgen compiler", weil sie diesen am liebsten immernoch mit in Delphi 1 erstelltem Sourcecode füttern wollen.

Außerdem bin ich mir nicht sicher und kann mir kaum vorstellen, dass man bei einer VCL Anwendung plötzlich das ARC Model angeschaltet hat.
Soweit ich weiß, wird das eher für die Apple Plattformen nützlich sein (wie auch im Blogpost von Arnaud am Ende erwähnt wurde).

[stahli]

Geschrien hat ja noch keiner.
Aber u.U. ist das eine weitreichende Änderung (vielleicht Verbesserung?), über die die Entwickler aufgeklärt werden sollten.
Dann gäbe es auch weniger Spekulationen darüber.

[himitsu]

Jupp, im Augenblick herst erstmal nur Unwissen, Angst und bissl Panik.

Grundsätzlich haben wir ja nichts gegen Neuerungen.
Aber die meisten aktuellen Änderungen/Neuerungen waren (abgesehn von Unicode und 64 Bit, bzw. XPlattform) eher nur "Erweiterungen", welche die Grundfunktionen fast nie grundlegend veränderten.

Hier ist es ja so, daß quasi heimlich im Hintergrund an einer (bewährten etablierten) Grundfunktion aus'm letzten Jahrtausend rumgespielt wird
und das bisher eher nur zufällig entdeckt wurde, weil ausversehn Einige im Quellcode drübergestolpert sind, es aber vorher scheinbar nichtmal erwähnt wurde.

[Stevie]

Zitat von stahli:

Geschrien hat ja noch keiner.

Hier vielleicht

Zitat von himitsu:

Hier ist es ja so, daß quasi heimlich im Hintergrund an einer (bewährten etablierten) Grundfunktion aus'm letzten Jahrtausend rumgespielt wird und das bisher eher nur zufällig entdeckt wurde, weil ausversehn Einige im Quellcode drübergestolpert sind, es aber vorher scheinbar nichtmal erwähnt wurde.

Es ist kein Geheimnis, dass ARC in Delphi Einzug halten wird.

[himitsu]

Das kann man auch so lesen, daß es ein neues (zusätzliches) Objektformat gibt ... daß direkt an TObject rumgeschraub wird, kann ich da nicht rauslesen.