AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Object-Pascal / Delphi-Language Delphi Warum sind Klassenoperatoren nicht bissl intelligenter?

Warum sind Klassenoperatoren nicht bissl intelligenter?

Ein Thema von himitsu · begonnen am 9. Mär 2020 · letzter Beitrag vom 10. Mär 2020
Antwort Antwort
Seite 1 von 2  1 2   
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.014 Beiträge
 
Delphi 12 Athens
 
#1

Warum sind Klassenoperatoren nicht bissl intelligenter?

  Alt 9. Mär 2020, 18:56
Delphi-Version: 10.3 Rio
Warum kann der Compiler nicht auch mal etwas Intelligenz zeigen und den impliziten Cast benutzen, anstatt beim if List[0] = 0 then aufzugeben?
Andersrum geht if 0 = List[0] then zum Glück auch nicht, obwohl der Compiler dort ja schon weiß, dass der Vergleich einen Integer ordinalen Typen haben möchte.
Delphi-Quellcode:
type
  TTestItem = record
  private
    FValue: Integer;
    function GetValue: Integer;
    procedure SetValue(const Value: Integer);
  public
    class operator Implicit(const Value: Integer): TTestItem; inline;
    class operator Implicit(const Value: TTestItem): Integer; inline;
    property RInt: Integer read GetValue;
    property WInt: Integer write SetValue;
    property RWInt: Integer read GetValue write SetValue;
  end;

  TTestList = record
  private
    FItems: TArray<TTestItem>;
    function GetItem(DummyIndex: Integer): TTestItem;
    procedure SetItem(DummyIndex: Integer; const Value: TTestItem);
  public
    property Item[DummyIndex: Integer]: TTestItem read GetItem write SetItem; default;
  end;

procedure TForm1.FormCreate(Sender: TObject);
var
  List: TTestList;
begin
  List[0] := 123; // Implicit:TTestItem > SetValue > SetItem

  List[0].WInt := 456; // GetItem > SetValue > lost
  if List[0] <> 456 then lost;

  List[0].RWInt := 789; // GetItem > SetValue > lost
  if List[0] <> 789 then lost;

//if List[0] = 0 then ; // GetItem > Implicit:Integer > GetValue = [dcc32 Fehler] E2015 Operator ist auf diesen Operandentyp nicht anwendbar

  if Integer(List[0]) = 0 then ; // GetItem > Explicit > Implicit:Integer > GetValue

  if List[0].RInt = 0 then ; // GetItem > GetValue

  if List[0].RWInt = 0 then ; // GetItem > GetValue
end;
Oder hier einfach mal die Reihenfolge optimaler anpassen?
Delphi-Quellcode:
type
  TTest2 = record
  private
    FValue: Integer;
  public
    class operator Add (const LeftValue: TTest2; RightValue: Integer): Integer;
    class operator Equal(const LeftValue: TTest2; RightValue: Integer): Boolean;
    class operator Implicit(const Value: Integer): TTest2;
    class operator Implicit(const Value: TTest2): Integer;
  end;

procedure TForm1.FormCreate(Sender: TObject);
var
  X: TTest2;
begin
  if X = 0 then ; // Equal(Rec,Int)
  if 0 = X then ; // Implicit:Integer > Implicit:TTest2 > Equal(Rec,Int) ... erst rechts, dann links?
Klar, jetzt kann man natürlich auch noch alle möglichen Vergleichsoperatoren und alles auch nochmal umgedreht reinmachen, aber schlauer wäre es mit etwas mehr Intelligenz.

Und das mit den Settern läst sich dadurch verhindern, dass der Record keine Setter bekommt. (implizite Casts als Zuweisung funktionieren erstaunlicher Weise)
Angehängte Dateien
Dateityp: pas Unit1.pas (4,2 KB, 1x aufgerufen)
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (10. Mär 2020 um 11:59 Uhr)
  Mit Zitat antworten Zitat
Andreas13

Registriert seit: 14. Okt 2006
Ort: Nürnberg
709 Beiträge
 
Delphi XE5 Professional
 
#2

AW: strunzdoofe Kassenoperatoren?

  Alt 9. Mär 2020, 19:00
<gelöscht>: hat sich erledigt.
Grüße, Andreas
Wenn man seinem Nächsten einen steilen Berg hinaufhilft, kommt man selbst dem Gipfel näher. (John C. Cornelius)

Geändert von Andreas13 (10. Mär 2020 um 14:04 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.014 Beiträge
 
Delphi 12 Athens
 
#3

AW: strunzdoofe Kassenoperatoren?

  Alt 9. Mär 2020, 19:04
glaub schon
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
Dennis07

Registriert seit: 19. Sep 2011
Ort: Deutschland
479 Beiträge
 
Delphi 11 Alexandria
 
#4

AW: strunzdoofe Klassenoperatoren?

  Alt 9. Mär 2020, 19:11
Tut mir leid, aber ich checke dein Problem gerade nicht.
Der Equal-Klassenoperator funktioniert bei mir ohne Probleme in dieser Konstellation. Egal wie herum man die Operanden schreibt. Wenn du diesen aber nicht definierst, dann ist es natürlich klar, dass hier kein Vergleich möglich ist.
Kannst du evtl nochmal kurz erläutern, was dein Problem ist?

Was wirklich nicht funktioniert, egal, ob du den Impliziten Operator überlädst, ist, wenn du versuchst, einen Wert des Typs an eine Funktion zu übergeben. Das wäre durchaus mal einen Fix Wert.

Delphi-Quellcode:
procedure Poop(Arg: Integer);
begin
  //...
end;

begin
  Poop(List[0]); // Jeht nüscht
end.
Dennis
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.014 Beiträge
 
Delphi 12 Athens
 
#5

AW: strunzdoofe Klassenoperatoren?

  Alt 9. Mär 2020, 19:43
JA, WENN man diesen Operator einbaut.
Aber stell dir mal vor das wäre Intelligent und würde den ImplicitCast benutzen.

Und wierum hat einen großen Einfluss auf die Qualität des Vergleichs. (siehe TTest2)
In meinem Fall kann dieses Verhalten sogar einen Fehler erzeugen, wenn sich der Record nicht in einen Integer casten lässt.

Zitat:
Poop(List[0]);
Geht doch, denn hier wird natürlich der ImplicitCast verwendet.


Das hier ist noch ein einfaches Beispiel gewesen, welches ich als Test erstellt hatte.
Der originale Record, wo ich es verwenden wollte, würde jetzt bestimmt nochmal locker 100 weitere Operatoren benötigen, wenn ich dafür alle möglichen Konstellation in allen Richtungen reinmachen müsste.
Stattdessen bleibt mir wohl eher alles wegzuwerfen und eine weniger schöne Syntax zu verwenden, anstatt die paar Konvertierungen nur in den Record zu packen.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu ( 9. Mär 2020 um 19:58 Uhr)
  Mit Zitat antworten Zitat
Dennis07

Registriert seit: 19. Sep 2011
Ort: Deutschland
479 Beiträge
 
Delphi 11 Alexandria
 
#6

AW: strunzdoofe Klassenoperatoren?

  Alt 10. Mär 2020, 04:57
Ups, ja, das geht tatsächlich.

Aber es funktioniert nicht in jeder Konstellation. Bin ganz früher über das hier selbst gestolpert, als ich die Operatoren ausprobiert habe...

https://stackoverflow.com/questions/...hod-parameters

Das funktioniert nämlich nicht...
Dennis
  Mit Zitat antworten Zitat
Daniel
(Co-Admin)

Registriert seit: 30. Mai 2002
Ort: Hamburg
13.919 Beiträge
 
Delphi 10.4 Sydney
 
#7

AW: strunzdoofe Klassenoperatoren?

  Alt 10. Mär 2020, 05:56
Bitte gib Deinem Thema einen aussagekräftigen Titel ...
Daniel R. Wolf
mit Grüßen aus Hamburg
  Mit Zitat antworten Zitat
Rollo62

Registriert seit: 15. Mär 2007
3.882 Beiträge
 
Delphi 12 Athens
 
#8

AW: strunzdoofe Klassenoperatoren?

  Alt 10. Mär 2020, 09:52
Warum kann der Compiler nicht auch mal etwas Intelligenz zeigen und den impliziten Cast benutzen,
Das ist kein Problem, sondern ein Feature: die starke Typisierung bei Pascal
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.014 Beiträge
 
Delphi 12 Athens
 
#9

AW: strunzdoofe Klassenoperatoren?

  Alt 10. Mär 2020, 12:07
Es geht ja noch weiter ... Delphi/Pascal kennt keine Unterscheidung zwischen Bitwise und Logical, bei and/or/xor, aber du kannst beides Deklarieren (für das komische BCPP),
was erstmal nicht schlimm ist, wenn dir der Compiler eine Meldung geben würde, dass er das Andere nicht verwendet.

Oder wenn du Equal deklariert hast, dann könnte man das für NotEqual mitverwenden, wenn dieses nicht Deklariert wurde.
Oder warum nicht gleich "eine" CompareMethode für Alles? mit den drei Ergebnissen -1, 0 und 1 anstatt 6 Methoden. Delphi-Referenz durchsuchenCompareValue
Bzw. wenn etwas davon nicht deklariert wurde, dann könnte der Compiler mit 1 bis 2 Aufrufen alles Andere daraus generieren. (z.B. Equal und LessThan reicht aus, um alle Anderen zu emulieren)

Bei Add, And, Or und Xor ist die Reihenfolge der Parameter egal, also würde eine Variante reichen und der Compiler dreht die anderen Möglichkeiten einfach um.

Ich hatte mir auch ein class operator In(const LeftValue: TTestItem; const RightValue: array of Integer): Integer; deklariert, aber ist bei der Aufrufstelle was blöde.
Delphi-Quellcode:
// meldet mir out of Bonds, weil er das [] als Byte-Set interpretiert und erst dann die Typprüfung mit dem Ziel macht
if MyRec in [1000, 2000] then
// aber hier weiß er vom := , dass es ein IntegerArray werden soll, warum schaut er dann bei meinem Record nicht auch mal nach was er für Typen erwartet, schließlich wurde das vorher schon geparst
//Arr := [1000, 2000];

var Arr: TArray<Integer>;
if MyRec in Arr then // geht
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (10. Mär 2020 um 12:15 Uhr)
  Mit Zitat antworten Zitat
Dennis07

Registriert seit: 19. Sep 2011
Ort: Deutschland
479 Beiträge
 
Delphi 11 Alexandria
 
#10

AW: Warum sind Klassenoperatoren nicht bissl intelligenter?

  Alt 10. Mär 2020, 12:15
Jo, das mag unlogisch erscheinen. Ich denke allerdings, dass es halt nunmal ist, wie der Compiler intern die Operatoren verwaltet. Das Problem ist nunmal, dass NotEqual halt nicht in jedem Fall not Equal entspricht.
Eine Ungleichheit (oder eine Gleicheit) stellt man bei manchen Typen halt unterschiedlich fest, und ein generischer Vergleich wäre ja da nochmal etwas anderes (und auch nicht auf jeden Typen anwendbar, beispiel:

Delphi-Quellcode:
type
  TMyPoint = record
    X, Y: Integer;
end;
Jetzt stell da mal eine sinnvolle Deklaration für einen Compare -Operator auf... Geht nicht. Dennoch wären Equal , NotEqual , GreaterThan , ... problemlos möglich.
Dennis
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:42 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz