Operator Overloading for CLASSES (not records!)

[TheSledgeHammer]

Wenn ich mal zusammenfassen darf: die Möglichkeit Operatoren zu überladen, ist wohl nur auf reinen ARC-Systemen möglich, sehe ich das jetzt richtig? Für nonArc-Systeme, also solche, bei denen man einen richtigen GC bräuchte oder aber selbst alle Objekte wieder frei gibt, ist das nicht realisierbar?

[TheSledgeHammer]

Zitat:

Zitat von himitsu (Beitrag 1455855)

Zitat:

Zitat von Codehunter (Beitrag 1455853)

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... :gruebel:

[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

Delphi-Quellcode:

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.

[himitsu]

Zitat:

Zitat von Stevie (Beitrag 1455861)

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)

[Codehunter]

Zitat:

Zitat von himitsu (Beitrag 1455855)

Zitat:

Zitat von Codehunter (Beitrag 1455853)

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" :lol:

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:

Zitat von freimatz (Beitrag 1455914)

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

[Stevie]

Zitat:

Zitat von Codehunter (Beitrag 1455906)

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.

Das geht wie gesagt nur bei Typen, denen man sowieso Operatoren verpassen kann, wie Records oder Klassen (bei Klassen mit der schon besprochenen Einschränkung). Nicht aber bei string, Integer und Co. Ich hab z.B. weitere Operatoren für System.Rtti.TValue geschrieben, die Anwendung finden, wenn ich die entsprechende Unit einbinde.

Zitat:

Zitat von Codehunter (Beitrag 1455906)

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.

Die unterstützung von nicht ordinalen Typen in einem switch/case hat aber in den mir bekannten Sprachen nichts mit Operatoren auf den unterstützten Typen zu tun sondern sind in der Sprachsyntax bzw dem Compiler verankert, der dann weiß, wie er damit umzugehen hat. Bei Ordinaltypen kann eine Jumptable auf den passenden Wert gebaut werden, so macht Delphi das, aber bei anderen Typen müssen andere Strategien her, die in aller Regel der Compiler entscheidet (wie z.B. in C# bei string). Kommen dann noch so interessante Dinge wie Pattern matching hinzu, wirds komplexer.

Bzgl Verbesserung des case of Statements: einfach mal nen Vote für RSP-16478 abgeben und die Daumen drücken.

[freimatz]

Zitat:

Zitat von Codehunter (Beitrag 1455920)

Zitat:

Zitat von freimatz (Beitrag 1455914)

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

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

[himitsu]

Nativ fehlt halt so Einiges in Delphi, was man schonmal gebraucht hätte. (Einiges gibt es zum Glück von Fremdanbietern, was aber auch schnell den Gesamtpreis von Delphi etwas in die Höhe treibt)

DefaultPropery für Strings (das mit dem Default-Attritut ist schon blöd, denn Eines steht davor und das Andere dahinter und wenn ich jetzt frage wer von euch überhaupt weiß dass es sowas gibt, dann hebt bestimmt kaum jemand die Hand), Attribute hinter dem was man beschreiben will (statt davor/drüber), kleine Makros, assoziative Arrays, ein besseres CASE, ...

Nicht schön, aber was soll's.

Delphi-Quellcode:

case IndexStr(S, ['A', 'B', 'C']) of
  0{A}: ...;
  1{B}: ...;
  2{C}: ...;
end;

type TX = (A, B, C);
//case TX(IndexStr(S, ['A', 'B', 'C'])) of
case TX(GetEnumValue(TypeInfo(TX), S)) of 
  A: ...;
  B: ...;
  C: ...;
end;