Hallo Community,

zunächst mal: ja, der Titel ist absichtlich in Englisch, damit ihn Leute auch finden, wenn sie in Google englische Begriffe eingeben.

Zur Sache: Laut der aktuellsten Doku von Emba (Stand 23.01.2020) bzgl. der Überladung von Operatoren steht ganz klar im Text geschrieben, dass dieses Feature ausdrücklich auch für Klassen verwendbar wäre und nicht nur für Records:
http://docwiki.embarcadero.com/RADSt...#Codebeispiele

Ihr könnt es euch denken: der Konjunktiv steht da nicht umsonst. So, wie es dort beschrieben ist, geht es natürlich nicht - wäre auch zu schön gewesen, aber warum überrascht mich das nicht?
Es hat mich schon stutzig gemacht, dass die Codebeispiele nur für Records geschrieben sind, aber man glaubt ja als naiver Entwickler zunächst mal das, was in der Doku geschrieben steht...

Ein "Glück" - und deshalb formuliere ich ja diesen Beitrag auch - haben schlaue Leute eine Alternative gefunden. Diese wurde auch schon hier in den "Delphi-News aus aller Welt" verlinkt, allerdings ist dort der Link defekt.
(https://www.delphipraxis.net/194454-...B7-github.html)
Daher habe ich hier mal den Link nochmal heraus gesucht: https://gist.github.com/lynatan/886e...dd89ed42ab2214

Jetzt sieht es aber so aus, dass diese Alternative nicht so ganz klappt, zumindest nicht für den Equal-Operator. Hat beim Thema "operator overloading" bei Klassen jemand Erfahrung, die mir/uns da weiterhelfen kann?

Ich habe mich vor einiger Zeit mit einem verwandten Thema beschäftigt. Deshalb finde ich das hier grad sehr interessant. Aber für Unwissende: Was bitte ist denn ein Non-ARC-Compiler?

Hallo,

Zitat von Codehunter:

Was bitte ist denn ein Non-ARC-Compiler?

ARC= Automatic Reference Counting -> Ein Compiler ohne automatischer Referenzzählung. Der Win32/64 Delphi-Compiler oder die .Net-Compiler. Bei den anderen Delphi-Compilern will Embarcadero ja wieder weg vom ARC. Ich hätte gern ein Mix aus ARC/Non-ARC.

Zitat von Codehunter:

Ich habe mich vor einiger Zeit mit einem verwandten Thema beschäftigt. Deshalb finde ich das hier grad sehr interessant.

Sehr schöner Artikel! Aber auch hier: nur für Records.

Ich hab auch noch irgendwo beim Herumstöbern eine Erklärung gefunden, warum bisher kein operator overloading für Klassen implementiert wurde; hatte irgendwas mit dem Garbage Collector (GC) zu tun. Erklärt wurde das so, dass für jedes Mal, wo ein Operator ausgeführt wird, eine weitere Instanz der Klasse erzeugt werden müsste. Und die wird nur intern erzeugt, aber nicht freigegben und da es mit dem GC in Delphi ja nun etwas schwierig ist, würde diese Instanz als MemLeak weiter sein einsames Dasein fristen. So ganz steig ich da auch nicht durch.

Aber das kann ich irgendwie nicht so recht glauben, dass man das mittlerweile nicht irgendwie gebacken bekommt. Ich sag's mal so: andere Programmiersprachen können's doch auch!? Und offenbar hat man das für iOS im Jahr 2013 schon umgesetzt, dann sollte man doch bis ins Jahr 2019 auch irgendwie für nicht-iOS-Systeme eine Lösung parat haben! Fehlender GC hin oder her...

Und besonders lustig wird's dann, wenn in der Doku geschrieben steht, dass es gehen sollte.

Zitat von TheSledgeHammer:

Und besonders lustig wird's dann, wenn in der Doku geschrieben steht, dass es gehen sollte.

Weil es für die ARC-Compiler ja geht.

Zitat von TheSledgeHammer:

hatte irgendwas mit dem Garbage Collector (GC) zu tun

ARC = einfache billigversion eines komplexen Garbage Collectors

Mit ARC werden Objekte (TObject usw.) wie Interfaces behandelt, also automatisch freigegeben, wenn alle Variablen weg sind. (dafür wird Free einfach so still und heimlich ignoriert)

Die ClassOperators benötigen aber eine automatische Speicherverwaltung, da der Entwickler (Du) das hier nicht selbst macht, bzw. oft garnicht machen kann. (Free aufrufen, wenn nicht mehr benötigt)

Zitat von einbeliebigername:

Ich hätte gern ein Mix aus ARC/Non-ARC.

Ich hätte auch gern [WeakRef] im Non-ARC-Compiler für interface-Variablen.
Und dass der Compiler unbekannte Attribute nicht einfach so still und heimlich ignoriert. (da wenigstens eine Warnung anzeigt)

Für Records wäre auch ein ClassOperator für New, Copy und Dispose praktisch, damit man dort z.B. auch Pointer und Objekte selbst behandeln kann, die im Record stecken.
Hatte da vor vielen Jahren mal einen QC geschrieben, sogar mit Lösung was wo wie nötig wäre (wenige Codezeilen zu ändern), aber .... ich warte immernoch.



Insgesamt macht ARC und NonARC hier echt Spaß, wenn man versucht einen objektorientierten Code zu schreiben, der auf allen Platformen funktioniert. Da kann man sich oft nur die Haare raufen und aufgeben. (außer man stellt alles komplett auf Interfaces um)

Zitat von TheSledgeHammer:

Sehr schöner Artikel! Aber auch hier: nur für Records.

Genau genommen sind Records auch Klassen.

Zitat von TheSledgeHammer:

Ich hab auch noch irgendwo beim Herumstöbern eine Erklärung gefunden, warum bisher kein operator overloading für Klassen implementiert wurde; hatte irgendwas mit dem Garbage Collector (GC) zu tun. Erklärt wurde das so, dass für jedes Mal, wo ein Operator ausgeführt wird, eine weitere Instanz der Klasse erzeugt werden müsste.

Das glaube ich schon. Wenn man genau hinschaut, mache ich das in meinem Tutorial sogar absichtlich. Für einfache Klassen müsste es trotzdem gehen. Ich sehe noch nicht mal das Freigeben als das große Problem an. Eher schon das Instantiieren der Klassen. Die meisten Klassen haben ja parametrisierte oder überladene Konstruktoren. Wie sollte der Compiler da wissen, welcher der richtige ist?

Nee, das Erstellen machst du ja, in den Operatoren, und gibst es als Result zurück.
Drum ist dem Compiler das vollkommen egal.

Zitat von Codehunter:

Genau genommen sind Records auch Klassen.

In Delphi ist es andersrum.
Klassen sind intern ein Record mit einem Pointer davor. (und der Pointer zeigt in die Mitte des Records, statt auf dessen Anfang)

In Sowas wie Java, .NET und Dergleichen, da stimmt deine Aussage schon, wobei dort oft eher alles Objekte sind, soger ein schnöder Integer (drum kann der auch NULL bzw. EMPTY werden).

Ich bin mir ziemlich sicher, dass der equals operator für Klassen auch auf ARC keine Beachtung findet, wenn left und right vom Typen sind, dem man diesen Operator verpasst.
Denn damit würde man den schon funktionierenden = Operator für TObject überschreiben können.

Genauso kann man auch mit dem "&&op_*" Hack in einem helper einem Integer nicht seine = oder <, > Operatoren umschreiben.

Es gibt übrigens 2 Arten von Operatoren: die, die neue "Instanzen" zurückgeben, wie z.B. Addition und solche die nur Boolean o.ä. zurückliefern wie Vergleiche - letztere wären auch ohne ARC komplett problemlos möglich.

Zitat von himitsu:

Ich hätte auch gern [WeakRef] im Non-ARC-Compiler für interface-Variablen.

Gibt's seit XE8 oder so (es heißt übrigens [Weak])

Zitat von himitsu:

Für Records wäre auch ein ClassOperator für New, Copy und Dispose praktisch, damit man dort z.B. auch Pointer und Objekte selbst behandeln kann, die im Record stecken.

Wird früher oder später kommen - fast wär's mit 10.3 so weit gewesen - aber weint bitte nicht, wenn ihr seht, wie inperformant das implementiert ist.

Zitat von Uwe Raabe:

Zitat von TheSledgeHammer:

Und besonders lustig wird's dann, wenn in der Doku geschrieben steht, dass es gehen sollte.

Weil es für die ARC-Compiler ja geht.

Das steht da aber nicht, dass das nur für ARCs gilt...