Warum ARC abgeschafft?

[stahli]

Warum ist in D 10.4 ARC für mobile Anwendungen abgeschafft?

Dass es einheitlich für Desktop und Mobil sein sollte, ist klar.
Aber wäre es nicht gut gewesen, ARC auch für Desktop einzuführen?

Ich arbeite nur noch mit Interfaces und finde ARC extrem angenehm.
Einziger Nachteil ist das doppelte Schreiben von Interface- und Klassendeklarationen.

Wenn ich mal Objekte freigeben muss, dann nervt mich das eher.

Was spricht gegen ARC?


Etwas Speicherverbrauch und Leistungsverlust stört mich nicht, wenn das nicht zu spüren ist. Die Entwicklungsarbeit wird jedenfalls deutlich vereinfacht (wenn die Interfacedeklarationen etwas automatisiert werden), was mir die Sache auf jeden Fall wert ist.

Mobil habe ich noch nichts entwickelt. Aber wie seht Ihr die Abschaffung von mobilem ARC?

[Der schöne Günther]

Zitat:

Zitat von stahli (Beitrag 1465798)

Ich arbeite nur noch mit Interfaces und finde ARC extrem angenehm.

Da gilt ja auch weiterhin ARC, du hast also nichts verloren 😎

Zitat:

Zitat von stahli (Beitrag 1465798)

Einziger Nachteil ist das doppelte Schreiben von Interface- und Klassendeklarationen.

Interfaces haben auch so noch ganz andere Vorteile, außer der automatischen Freigabe. Keine Bange, es lohnt sich. Und wer nicht gerne viel tippt ist bei Pascal sowieso falsch :duck:

Zitat:

Zitat von stahli (Beitrag 1465798)

Was spricht gegen ARC?

Dass ein Großteil der Delphi-Bibliotheken (dazu gehört z.B. auch die komplette VCL) explizit auf ein manuelles Verwaltungssystem setzt? Code der mit irgendwelchen Ownern und manueller Freigabe von Objekten entstanden ist kannst du nicht auf ARC bringen. Den Aufwand tut sich niemand an.

Zitat:

Zitat von stahli (Beitrag 1465798)

Aber wie seht Ihr die Abschaffung von mobilem ARC?

Gut dass es endlich einheitlich ist. Ich hatte 2016 mal einen Versuch gewagt mit dem RAD Studio was für iOS/Android zu machen, viel Code ließ sich überhaupt nicht oder nur unter zu großem Aufwand wiederverwenden.

[Stevie]

Die Akzeptanz von ARC war von vornherein eher mau.

Das lag zum einen daran, dass man ebend nicht einfach seinen Krams nehmen konnte und es unter ARC lief sondern sich mitunter ein Arm und Bein ausreißen musste.

Zusätzlich war die Implementierung von ARC sauschlecht, was Performance angeht dazu nur 2 Dinge erläutert: 1. die ObjAddRef und ObjRelease Methoden waren virtuell, somit äußert schlecht zu Optimieren für die Häufigkeit der Aufrufe 2. viele Parameter in RTL und FMX waren nicht const, somit wurden die zuvor erwähnten Methoden öfter als notwendig aufgerufen.

Es fehlten wichtige Features, um ohne riesengroße Hacks fehlerfrei entwickeln zu können, wie z.B. die Möglichkeit, anzugeben, was in anonymen Methoden wie gecaptured werden sollte (siehe https://quality.embarcadero.com/browse/RSP-10176 und https://quality.embarcadero.com/browse/RSP-16251)

[Uwe Raabe]

Zitat:

Zitat von stahli (Beitrag 1465798)

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

Ein Problem dabei war wohl, daß die VCL nicht mal eben so umgestellt werden kann. Da aber eine deutliche Mehrheit der bestehenden Applikationen VCL sind und auch noch eine ganze Weile sein werden, hätte das wohl ein ziemliches Erdbeben ausgelöst. Insofern blieb zur Vereinheitlichung einfach nur diese eine Option.

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

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

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)