Warum ARC abgeschafft?

[himitsu]

Willst du uns umbringen?
ARC im Windows ... dann würe ja garkein vorhandenes Programm mehr im 10.4 lauffähig sein.

Zitat:

Aber wäre es nicht gut gewesen, ARC auch für Desktop einzuführen?

Davor hatte ich große Angst und Andere bestimmt auch.
Es war ja angekündigt, dass es irgendwann, in ferner Zukunft, einheitlich werden soll, aber damals klang es noch so, als wenn am Ende alles zum ARC überläuft.


So richtig abgeaschafft wurde es ja nicht ... bissl ist wohl noch da.

Aber der Hauptgrund ist eben, dass nun endlich alle Platformen "vereinheitlicht" sind und somit ein Code viel einfacher zu portieren und wiederzuverwenden ist,
abgesehn vom großen Wiederstand dagegen.

Ich bin aber auch noch am rumschauen was nun wie genau vereinheitlich wurde und was sich nun genau geändert hat und was nun alles mit wem wierum "vereinheitlicht" wurde.

Zuerst fing ich an der Stelle an zu suchen, als ich das "unified memory management" geört hatte.
https://www.delphipraxis.net/204423-...m-windows.html



Ich hatte das letzte halbe Jahr über bissl rumgeschaut, wie ich meine Komponenten auch für Nextgen zum laufen bekomme,
ohne vom ARC gepisackt zu werden und ohne alles durch Interfaces doppelt programmieren zu müssen und bei vielen Property unnötig durch erzwungene Getter/Setter erschlagen und ausgebremst zu werden.

Nun hatte ich von jemandem die virtuellen Interfaces aufgegriffen und teilweise über die Generics in einer Art "Vererbung" auf Records angewendet.
Jetzt war das Konzept vor Kurzem lauffähig und einfach "benutzbar" und ich kann nun "glücklich" alles wieder wegwerfen (das Konzept als Proof-of-concept bleibt erhalten)
und kann nun auch Dank der neuen Record-Operatoren das machen, was ich ursprünglich schon vor 5 Jahren vor hatte.

[stahli]

Ok danke.

Zusammenfassend verstehe ich es so: ARC ist nicht generell schlecht aber schwer umsetzbar für bestehende Frameworks (VCL und Co). Und unterschiedliche Handhabung auf verschiedenen Zielplattformen sollte vermieden werden.


@Schönling

Ich hatte nicht die Befürchtung, dass das einen Einfluss auf Interfaces hat. Dabei bleibe ich so oder so.

[himitsu]

Jo, bei Interfaces war es schon immer so und wird auch so bleiben, wie es war.

Mit ARC versuchte man deren Verhalten (automatische Freigabe), und noch bissl mehr (z.B. Weak-Referenzen), brutal in die alten Delphi-Objekte reinzuprügeln.

[MEissing]

Non-ARC hat auch einen Performance-Vorteil. Nicht viel... aber etwas.

[bernau]

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

[himitsu]

Zitat:

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.

Das durftest du auch. (so halb)

Jemand kam nur auf die saudämliche geniale Idee die Funktion dafür umzubenennen (DisposeOf), damit dein Code auch garantiert nicht abwärtskompatibel ist.

Zitat:

Try-Finally fällt weg

Nicht wirklich,

aber ja, das Eigene schon, denn Delphi baut bei gemanagten lokalen Variablen ein implizites Try-Finally ein. (quasi im Begin und End deiner Prozedur)

[Harry Stahl]

Zitat von bernau:

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 von bernau:

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 von jfheins:

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.

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


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 von jfheins:

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)