Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Die Delphi-IDE (https://www.delphipraxis.net/62-die-delphi-ide/)
-   -   F2084 beim kompilieren in Win32 (https://www.delphipraxis.net/213121-f2084-beim-kompilieren-win32.html)

BigAl 30. Mai 2023 21:39

F2084 beim kompilieren in Win32
 
Hallo zusammen,

gestern hat mich ein interner Fehler ("[dcc32 Fatal Error] (...): F2084 Internal Error: C2210") ziemlich viele Nerven gekostet. Ich habe da jetzt einen Workaround, würde den Fehler aber trotzdem gerne melden. Dazu habe ich die recht umfangreiche Unit weit möglichst reduziert bzw. versucht den Fehler nachzustellen. Hier mal der Quellcode:
Delphi-Quellcode:
unit Unit1;

interface

type
  TClass1<T> = class
    FValue: T;
    procedure SetValue(const AValue: T);
  end;

  TClass2 = class(TClass1<Double>) // or <Extended> (e.g. <Single> works)
  end;

implementation

procedure TClass1<T>.SetValue(const AValue: T);
begin
  if AValue <> FValue then // <-- Here I get "[dcc32 Fatal Error] Unit1.pas(23): F2084 Internal Error: C2210"
    FValue := AValue;
end;

end.
Kann mal jemand testen ob es bei ihm auch einen Fehler gibt? Könnte ja immer noch an meinem System (oder an mir) liegen. Vielleicht übersehe ich ja was.

Der Fehler tritt nur bei Win32 auf (Win64 kompiliert). Natürlich macht der Code keinen Sinn und dient nur der Nachstellung des Fehlers.

Ach ja: Mein Workaraund nutzt jetzt halt einen IComparer<T> :-). Dann funktioniert es...

EDIT: Hab es noch weiter gekürzt.

jaenicke 30. Mai 2023 22:06

AW: F2084 beim kompilieren in Win32
 
Ja, den Fehler bekomme ich auch und die Lösung mit dem TComparer/IComparer ist auch korrekt.

Korrekt wäre z.B. ein "E2015 Operator not applicable to this operand type", wenn der Compiler mit dem Vergleich nicht klarkommt.

BigAl 30. Mai 2023 22:09

AW: F2084 beim kompilieren in Win32
 
Zitat:

Zitat von jaenicke (Beitrag 1522909)
Ja, den Fehler bekomme ich auch und die Lösung mit dem TComparer/IComparer ist auch korrekt.

Korrekt wäre z.B. ein "E2015 Operator not applicable to this operand type", wenn der Compiler mit dem Vergleich nicht klarkommt.

Danke für die Antwort. Wenn Du schreibst "korrekt wäre" heisst das man darf keine generische Typen auf Ungleichheit bzw. Gleichheit prüfen? Bin gerade verwirrt...

Uwe Raabe 30. Mai 2023 22:42

AW: F2084 beim kompilieren in Win32
 
Das es sowohl in Win64 als auch mit <Single> funktioniert, ist es wohl doch eher ein Fehler im Compiler. Schließlich darf das Compilieren nicht davon abhängen, welche Instanz man von dem Generic erzeugt.

Mach bitte einen QP-Eintrag dafür auf, damit das baldmöglichst behoben werden kann.

BigAl 30. Mai 2023 22:44

AW: F2084 beim kompilieren in Win32
 
Zitat:

Zitat von Uwe Raabe (Beitrag 1522911)
Das es sowohl in Win64 als auch mit <Single> funktioniert, ist es wohl doch eher ein Fehler im Compiler. Schließlich darf das Compilieren nicht davon abhängen, welche Instanz man von dem Generic erzeugt.

Mach bitte einen QP-Eintrag dafür auf, damit das baldmöglichst behoben werden kann.

Da war schon einer schneller: RSP-41205

himitsu 30. Mai 2023 22:49

AW: F2084 beim kompilieren in Win32
 
Man kann den Typen T einschränken, dann gibt es hier keine Probleme, wenn dieser Basistyp das Gewünschte bietet.
Ist es nicht eingeschränkt, dann kann es sein, dass es im Compiler keinen Default-Comparer für diesen Typ gibt, darum der Fehler.

Natürlich wäre eine mögliche Lösung selber über TComparer/IComarer zu gehen und es erst zur Laufzeit knallen zu lassen (bzw. nicht, falls es geht).

Ja, sinnvoller wäre es, wenn der Compiler einfach davon ausginge, dass es immer einen Comparer gibt und erst bei Implementation mit einem bestimmten Typ dann die Fehlermeldung kommt.

BigAl 30. Mai 2023 22:52

AW: F2084 beim kompilieren in Win32
 
Zitat:

Zitat von himitsu (Beitrag 1522913)
Man kann den Typen T einschränken...

Wie das? Geht doch bei Delphi nicht, oder? Oder habe ich Dich missverstanden?

Meinst Du das: https://docwiki.embarcadero.com/RADS...risierte_Typen)

himitsu 30. Mai 2023 23:31

AW: F2084 beim kompilieren in Win32
 
Teilweise geht es, aber da sollten die schon mal noch bissl was verbessern.

Also man kann z.B. sagen dass es eine Klasse ist, bzw. es einen Constructor gibt,
womit man Dinge wie .Create benutzen kann, ohne böse casten zu müssen.



Es kommt erstmal drauf an, was für Typen du benutzen willst.

jaenicke 30. Mai 2023 23:58

AW: F2084 beim kompilieren in Win32
 
Zitat:

Zitat von BigAl (Beitrag 1522910)
Danke für die Antwort. Wenn Du schreibst "korrekt wäre" heisst das man darf keine generische Typen auf Ungleichheit bzw. Gleichheit prüfen? Bin gerade verwirrt...

Früher ging da viel weniger. Heute sollte es an der Stelle gehen wie auch Uwe schrieb.

Aber was ich meinte ist, dass der Compiler, wenn er es irgendwo nicht können sollte, zumindest eine passende Fehlermeldung werfen muss.

BigAl 31. Mai 2023 06:20

AW: F2084 beim kompilieren in Win32
 
Zitat:

Zitat von jaenicke (Beitrag 1522917)
Zitat:

Zitat von BigAl (Beitrag 1522910)
Danke für die Antwort. Wenn Du schreibst "korrekt wäre" heisst das man darf keine generische Typen auf Ungleichheit bzw. Gleichheit prüfen? Bin gerade verwirrt...

Früher ging da viel weniger. Heute sollte es an der Stelle gehen wie auch Uwe schrieb.

Aber was ich meinte ist, dass der Compiler, wenn er es irgendwo nicht können sollte, zumindest eine passende Fehlermeldung werfen muss.

Ok. Jetzt habe ich Dich verstanden :-).

Naja. Vergleich auf Gleicheit (oder Ungleichheit) sollte bei einfachen Typen ja immer gehen. SizeOf(T) und dann schauen ob da die gleiche Byte-Folge steht sollte ja grundsätzlich kein Problem darstellen. Wäre halt cool, wenn man bei genrics die Typen einschränken könnte. Manchmal möchte man halt Generics nur für Zahlen machen (dann könnte man auch rechnen) oder nur für Integer-Typen oder, oder, oder. Ähnlich wie c++ (type_traits).


Alle Zeitangaben in WEZ +1. Es ist jetzt 07:32 Uhr.
Seite 1 von 2  1 2      

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