Warum ARC abgeschafft?

[Harry Stahl]

Zitat:

Zitat von bernau (Beitrag 1465976)

Nun auch mal meinen Senf zum Thema ARC.

Ich konnte mich noch nie mit ARC anfreunden. Wenn ich etwas erzeuge, dann möchte ich auch selber entscheiden, wann es freigegeben wird. Bin vielleicht darin etwas altmodisch.

Lästig ist allerdings der ganze try-finally-Block innerhalb einer Procedure.

Aber dafür hat man mit Managed Records ja nun eine Art ARC-Lite. Einfach eine TStringlist in ein Managed Record (TMyStringlistRec) reinschmeissen. Der Record übernimmt das Erzeugen und Freigeben der Stringlist. Nun muss nur noch in einer Procedure statt einer TStringlist der Record (TMyStringlistRec) deklariert werden und ich kann auf die Stringlist zugreifen. Um das Create und Free muss ich mich nicht mehr kümmern. Try-Finally fällt weg.

(Soviel zur Theorie. In der Praxis habe ich das noch nicht getestet.)

Wir hatten das ja beim letzten Delphi-Frühstück im Ansatz mal getestet. Ich habe das mit den Managed records inzwischen umgesetzt und kann Dir sagen, das funktioniert hervorragend. Habe mir bezogen auf Stringlists direkt 3 unterschiedliche Record-Typen angelegt :

TMyStringList // ganz normal
TMySortedStringList // StringList mit Sortierung
TMyStrictSortedStringList // sortiert und mit dupignore (also keine doppelten Einträge)


Wenn ich also in einer Prozedur eine einfache Stringlist brauche, geht das einfach so:

Delphi-Quellcode:

Procedure TuWasMitDatei (AFile: String);
begin
 
  if FileExists (AFile) then begin  // Wenn Datei nicht existiert wird Liste nicht gebraucht, Inline Var macht hier sinn

    var sl: TMyStringList; 
    sl.List.LoadFromFile (AFile);

    /// weitere aktionen

  end;
 
end;

Durch die Intialisierungsblöcke im Record wird die StringList automatisch erzeugt (und falls erforderlich wie gewünscht vorbelegt)
Nach Austritt aus der Procedur wird die Finalization im Record aufgerufen und die Liste freigegeben

--> Kein Try Finally mehr für solche Sachen in der eigenen Prozedur notwendig (in der Implementation
des Records auch nicht, das macht der Compiler automatisch)
--> Bei einer streng sortierten Liste erspare ich mir noch das Setzen von "sorted" und "dupIgnore"
--> Ein weiteres Feature, das ich liebe.

[jfheins]

Zitat:

Zitat von bernau (Beitrag 1465976)

Ich konnte mich noch nie mit ARC anfreunden. Wenn ich etwas erzeuge, dann möchte ich auch selber entscheiden, wann es freigegeben wird. Bin vielleicht darin etwas altmodisch.

So rein aus Interesse: Was für Fehler/Probleme versuchst du da zu vermeiden?

Ich frage, weil der allergrößte Teil von Fehlern (abgesehen von Semantik) in Software use-after-free sein dürfte. Und auch in der Arbeit haben wir ein ähnliches Problem des Kalibers "Wenn jeder einfach immer aufpassen und es richtig machen würde, hätten wir das Problem ja gar nicht. Wir müssen mehr aufpassen!"

Meine persönliche Meinung dazu ist, dass das keine zuverlässige Lösung ist. Entweder braucht man eine Sprache / ein Framework oder eine Coding-Konvention in der das nicht passiert (sprich: man kommt nicht auf die Idee sowas zu tun weil es überall schon anders gemacht wird) oder man lebt mit den Problemen.

Beispiel Angular / rxjs: Man muss ständig subscriben, um Callbacks zu registrieren. Man muss aber auch unsubscriben, sonst hat man ein memory leak. Wenn jeder im Team immer dran denkt: Alles super.
Wir messen unsere memory leaks in KB/s - aktuell sind wir bei 300 KB/s.

[himitsu]

Zitat:

Zitat von jfheins (Beitrag 1465985)

Wir messen unsere memory leaks in KB/s - aktuell sind wir bei 300 KB/s.

Zum Glück gibt es endlich 64 Bit,
sonst würde es nach 2 Wochen bissl eng. :shock:

Auch wenn wir schon zu lange auf 128 und 256 warten, aber Delphi ist ständig hinterher. :lol:


Kreuzreferenzen, verkettete Listen, multiple ParentOwner-Child-Verknubbelungen usw. .... endlich gibt es jetzt eine Möglichkeit das nun wieder ohne größere Umstände crossplatform hinzubekommen.

[Stevie]

Zitat:

Zitat von jfheins (Beitrag 1465985)

Beispiel Angular / rxjs: Man muss ständig subscriben, um Callbacks zu registrieren. Man muss aber auch unsubscriben, sonst hat man ein memory leak. Wenn jeder im Team immer dran denkt: Alles super.

Das würd ich aber eher als Fehler im Design bzw der Implementierung in rxjs bezeichnen - in Reactive.net musste auch nix unsubscriben, jede subscription isn disposable und die fliegen am Ende der Anwendung weg - klar die subscription ist so lange aktiv, aber das will man ja ggf. Ansonsten merkt man sich das Ergebnis von Subscribe und disposed es wenn die subscription weg soll.


RX ist aber ein gutes Beispiel, was in Delphi (abgesehen von der fast unmöglich implementierbaren generischen API) für ziemliches Kopfzerbrechen sorgt: die Speicherverwaltung für Objekte, die durch so ein Observable wandern. Da das asynchron, parallel und sonst läuft, je nachdem welche Operationen man auf son ein Observable anwendet, ist es einfach nicht möglich das händische manuelle Freigeben zu praktizieren sondern muss mit einem selbst implementierten Mechanismus (über smartpointer oder anders referenzgezählte Objekte) dafür sorgen - das fluppt einfach überall wo GC werkelt wunderbar (jaja, GC hat sein eigenes Päckchen an "tu das halt nicht", aber das haben wir schon an anderer Stelle ad nauseam diskutiert)