Operator Overloading for CLASSES (not records!)

[Codehunter]

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?

[himitsu]

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

[Stevie]

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.

[himitsu]

Zitat von Stevie:

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

Jo, gemerkt, aber im Win32 wird die Aangabe einfach vom Compiler ignoriert. (gut, ich glaub im 10.1 zuletzt ausprobiert)

[TheSledgeHammer]

Zitat von himitsu:

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)

Also wenn DAS stimmt, dann frag ich mich erstrecht, warum das operator overloading bei Records geht und bei Klassen nicht. Wenn eine Klasse nachher nichts anderes sein soll als ein Rekord...

[Stevie]

Klassen sind keine Records, und Records sind keine Klassen. Nur weil eine Klasse Felder wie ein Record hat und somit ein Teil ihres Speicherlayouts dem eines Records gleicht, macht es das nicht zum Record oder könnte gar dessen Funktionalitäten übernehmen - auch wenn intern für einige Dinge vom Compiler generierte record type Info genutzt wird (um zum Beispiel Felder für managed types korrekt zu finalisieren).

Klassen sind Referenztypen (Zeiger auf idR heapallokierten Speicher) und Records sind Wertetypen. Ja, man kann Zeiger auf Records haben und sie auch selbst aufm Heap allokieren, aber dann hantiert man nunmal mit Zeigern, also einem Referenztyp auf einen Wertetypen.

Records und die Operatoren, welche einen Record zurück geben arbeiten idR mit CopyRecord und der Standardmechanismus für Methoden, die einen Record zurückliefern, finden statt - Keine Heapallokation. Ein Operator, der Objekte zurückgeben würde, müsste eine Heapallokation durchführen. Generell noch kein Problem, aber wenn man zum Beispiel den Code x := a + b + c; hat, wird dort mind ein Temp Wert erzeugt (entweder a+b oder b+c) und erst das ergebnis dieses Temp Wertes mit dem dritten Wert landet in x, bei einer Heapallokation -> Speicherleck.

[Codehunter]

Zitat von himitsu:

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)

Um mal meinen Vater zu zitieren: "Alles ein Gemehr"

Was mich an der Sache hier viel mehr interessiert hat waren überladene Operatoren in Record Helpers. Das wäre wirklich eine nützliche Sache. Denn damit könnte man das Standardverhalten für einfache Typen lokal übersteuern. Beispiel:

Delphi-Quellcode:

var
  S: string;
begin
  S := 'foo';
  if S in ['foo', 'bar'] then begin
    {...}
  end;
end;

das wäre doch viel übersichtlicher als komplexe if-or-or-or-then-Konstrukte. Noch besser wäre natürlich, wenn case auch mit Strings umgehen könnte:

Delphi-Quellcode:

var
  S: string;
begin
  S := 'foo';
  case S of
    'foo': {...}
    'bar': {...}
  end;
end;

Für case-Anweisungen fehlt irgendwie ein überladbarer Operator. Equality spielt da zwar mit rein, aber case an sich ist nicht flexibel genug. Da ist switch-case in anderen Sprachen (z.B. Javascript, PHP) deutlich komfortabler.

[freimatz]

Ich bin froh, dass das nicht geht. Das verhindert damit oft unsauberen Code. (Wegen SoC https://en.wikipedia.org/wiki/Separation_of_concerns)

[Codehunter]

Zitat von freimatz:

Ich bin froh, dass das nicht geht. Das verhindert damit oft unsauberen Code. (Wegen SoC https://en.wikipedia.org/wiki/Separation_of_concerns)

Nach deiner Logik wäre ja die "Quelltextsauberkeit" umgekehrt äquivalent zur Anzahl verfügbarer Sprachfeatures

[freimatz]

Zitat von Codehunter:

Zitat von freimatz:

Ich bin froh, dass das nicht geht. Das verhindert damit oft unsauberen Code. (Wegen SoC https://en.wikipedia.org/wiki/Separation_of_concerns)

Nach deiner Logik wäre ja die "Quelltextsauberkeit" umgekehrt äquivalent zur Anzahl verfügbarer Sprachfeatures

Nein. Nach meiner Logik steht "das" steht für ein Sprachfeature und genau das erwähnte.