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

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

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

Zitat von stahli:

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

Zitat von stahli:

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

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

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.

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