Delphi 10.4 - Probleme mit Class Operatoren

[bytecook]

Hi Leute,

nutze die Tage grade um meinen Source von 10.2 auf 10.4 bringen. Dabei kommt es bei der Verwendung von Graphics32 zu einem Problem mit den Class Operatoren, die ich unter 10.2 nicht hatte.
In der Unit Gr32 ist TFloatPoint wie folgt definiert:

Code:

  TFloatPoint = record
    X, Y: TFloat;
  {$IFDEF SUPPORT_ENHANCED_RECORDS}
  public
    {$IFNDEF FPC}
    {$IFDEF COMPILERXE2_UP}
    constructor Create(P: TPointF); overload;
    {$ENDIF}
    constructor Create(P: TPoint); overload;
    constructor Create(X, Y: Integer); overload;
    constructor Create(X, Y: Single); overload;
    {$ENDIF}

    // operator overloads
    class operator Equal(const Lhs, Rhs: TFloatPoint): Boolean;
    class operator NotEqual(const Lhs, Rhs: TFloatPoint): Boolean;
    class operator Add(const Lhs, Rhs: TFloatPoint): TFloatPoint;
    class operator Subtract(const Lhs, Rhs: TFloatPoint): TFloatPoint;
    {$IFDEF COMPILERXE2_UP}
    class operator Explicit(A: TPointF): TFloatPoint;
    class operator Implicit(A: TPointF): TFloatPoint;
    {$ENDIF}

    class function Zero: TFloatPoint; inline; static;
  {$ENDIF}
  end;

So sollte eigentlich der Vergleich zweier Floatpoints mittels (fp1 <> fp2) oder eine simple Addition (fp1 + fp2) wie unter <= 10.2 kein Problem darstellen, ich erhalte jedoch die Fehlermeldung <[dcc32 Fehler] E2015 Operator ist auf diesen Operandentyp nicht anwendbar>
Habe ich bei 10.4 was übersehen? Danke vorweg!

[Der schöne Günther]

Kann es sein dass COMPILERXE2_UP bei 10.4 nicht gesetzt wird?

Wenn ich mir
https://github.com/graphics32/graphi...2_Compiler.inc
anschaue dann hat das noch keiner fitt für 10.4 gemacht.


(Und warum bauen die Leute das alles immer so dass man bei jedem Delphi-Update immer wieder alles anfassen muss? Ach ja, damit alles noch 20 Jahre bis Delphi 4 rückwärtskompatibel bleiben kann, stimmt).

[bytecook]

Zitat von Der schöne Günther:

Kann es sein dass COMPILERXE2_UP bei 10.4 nicht gesetzt wird?

Wenn ich mir
https://github.com/graphics32/graphi...2_Compiler.inc
anschaue dann hat das noch keiner fitt für 10.4 gemacht.


(Und warum bauen die Leute das alles immer so dass man bei jedem Delphi-Update immer wieder alles anfassen muss? Ach ja, damit alles noch 20 Jahre bis Delphi 4 rückwärtskompatibel bleiben kann, stimmt).

Stimmt - und da bin ich tatsächlich vorher drüber gefallen, aaargh, aber danke Dir!
Haja, bin zwischenzeitlich auf den Pull im Git gestossen. Luebbe hat das schon fit gemacht, siehe

https://github.com/graphics32/graphi...90e38c5497bb69

und

https://github.com/luebbe/graphics32

Mal schauen, was sonst noch rummotzt...

Lg,

Peter

[Uwe Raabe]

Zitat von Der schöne Günther:

(Und warum bauen die Leute das alles immer so dass man bei jedem Delphi-Update immer wieder alles anfassen muss? Ach ja, damit alles noch 20 Jahre bis Delphi 4 rückwärtskompatibel bleiben kann, stimmt).

Das ist auch kein Argument. Es gibt Konstrukte, die beides abdecken. (Aber ich sehe auch keinen Sinn darin, derart veraltete Versionen zu unterstützen)

[Stevie]

Sich gescheite aufwärtskompatible defines zu bauen oder einfach bestehende zu nutzen ist ja auch so schwer...

[himitsu]

Nja, verständlicher wäre es ja, sich im Code nicht an Versionen zu orientieren, sondern es in Funktionen aufzuteilen.
Stellt euch mal vor in Delphi kommt was in Version 29.0
und im Free Pascal in Version 3.3.0,
dann wird es in Version 30.0 wieder entfernt, aber bleibt im FreePascal drin.

Für uralte Delphi könnte man noch auf $IFDEF ConditionalExpressions mit $IFDEF VERxxx gehen (aber das ist sooooo alt, das hab ich aufgegeben zu supporten)
und ansonsten ist es nunmal besser auf $IF CompilerVersion >= x zu gegen, was in neuen Delphis nicht immer gleich abraucht (außer man muß wirklich was am Code ändern)

Dann gibt es noch RtlVersion, LibVersion usw.
Außerdem kann man im $IF Konstanten oder Declared() und Defined() benutzen und es auch noch wunderbar mit AND/OR verknubbeln, was beim IFDEF/IFNDEF manchmal ins perverse Ausartet.

[Sherlock]

Ich bin froh, daß ich keine alten Versionen unterstützen muss, Code derart kompliziert halten zu müssen, wäre mir ein Graus. Lesbarkeit ist 0, Pflegen kann man das Unkraut auch nicht wirklich. Es bleibt ja nicht bei den Klassendefinitionen, die Nutzung unterscheidet sich dann auch je weiter die Schere auseinander klafft. Neue Sprachfeatures in erzwungenermaßen abwärtskompatiblen Code einzubauen halte ich darum für unnötig riskant.

Sherlock