![]() |
Delphi-Version: 5
W1048 Unsichere Typumwandlung obwohl völlig ok
Ich habe in einem Projekt zwei Klassen mit ungefähr diesem Konstrukt:
Delphi-Quellcode:
In beiden Units wird die Zeile
unit MeineUnit;
interface uses System.TimeSpan; type TMyObject = class private/protected var someInternalField: TTimeSpan; public constructor Create(); end; implementation constructor TMyObject.Create() begin inherited Create(); someInternalField := TTimeSpan.Zero; // << W1048 end;
Delphi-Quellcode:
angekreidet, es sei eine "W1048 Unsichere Typumwandlung von 'TTimeSpan' nach 'TTimeSpan'".
someInternalField := TTimeSpan.Zero;
Potz Donner. Was läuft hier verkehrt? Ich kann das in einem neuen, leeren Projekt mit beiden Units mit 1:1 dem gleichen Inhalt nicht nachvollziehen. Ich bekomme es echt nicht rekonstruiert. |
AW: W1048 Unsichere Typumwandlung obwohl völlig ok
Zitat:
|
AW: W1048 Unsichere Typumwandlung obwohl völlig ok
Die Vereinfachung bezog sich nur auf den geposteten Code. Ich bekomme es mit EXAKT den gleichen Units nicht in einem leeren Projekt reproduziert. Oder habe ich das jetzt falsch verstanden?
Edit: Die Ursache lag in der Unit welche sich eine Instanz von
Delphi-Quellcode:
erstellt hat. Sie hatte
TMyObject
Delphi-Quellcode:
und ebendiese Unit redeklariert in ihrem Interface-Teil (weshalb auch immer)
uses [...], Spring
Delphi-Quellcode:
.
TTimeSpan = TimeSpan.TTimeSpan;
Wenn ich dort nun ein reines "TTimeSpan" benutze, dann ist es ein Spring.TTimeSpan und kein System.TimeSpan.TTimeSpan, obwohl es eigentlich nur ein Alias ist. Warum der Compiler nun den Konstruktor anstreicht und nicht die Zeile wo ein Spring.TTimeSpan einer System.TimeSpan.TTimeSpan-Property zugewiesen weiß ich allerdings auch nicht. Immerhin bin ich die Warnung los. |
AW: W1048 Unsichere Typumwandlung obwohl völlig ok
Zitat:
Also z.B. im interface-Teil wird TTimeSpan aus System.TimeSpan verwendet und im implementation-Teil hängt sowas wie dies dazwischen:
Delphi-Quellcode:
uses
System.TimeSpan; type TTimeSpan = type System.TimeSpan.TTimeSpan; |
AW: W1048 Unsichere Typumwandlung obwohl völlig ok
Siehe mein Edit darüber: Du liegst (wie immer) absolut richtig 8-)
Ich würde es einsehen wenn, wie in deinem Beispiel, ein neuer Typ deklariert wird. Hier ist es eigentlich nur ein Alias. Komisch. |
AW: W1048 Unsichere Typumwandlung obwohl völlig ok
Arbeitest du mit Laufzeitpackages?
Der Typ in im nachfolgenden Package ist nur eine Variable, die beim Laden der BPL die Referenz des aktuellen Typ im ersten Package bekommt. |
AW: W1048 Unsichere Typumwandlung obwohl völlig ok
Zitat:
Vielleicht aber liegt es daran dass er von Spring natürlich nicht jedes mal neu kompiliert sondern fertige DCUs nimmt? |
AW: W1048 Unsichere Typumwandlung obwohl völlig ok
Zitat:
Sherlock |
AW: W1048 Unsichere Typumwandlung obwohl völlig ok
PS: Das von Uwe war nur ein Beispiel, was wohl im Delphi nicht wirklich so aussieht.
Ein Typ gleichen Aufbaus, der aber nicht mit dem Anderen "kompatibel" ist? z.B. für Typen, welche eine andere Art von Daten enthalten, aber wo man sich sparen möchte es neu zu definieren.
Delphi-Quellcode:
Bei
type
TMyType = type Integer; procedure Test(X: Integer); overload; procedure Test(W: TMyType); overload;
Delphi-Quellcode:
wüsste der Compiler garnicht welche Funktion er nehmen soll.
TMyType = Integer;
|
AW: W1048 Unsichere Typumwandlung obwohl völlig ok
Das ist mir klar, und wenn man einen Bezeichner für den "neuen" Typen verwendet, der nicht für Unmut sorgt zB
Delphi-Quellcode:
, ist auch alles Bestens. Aber Spring scheint das ja nicht getan zu haben, darum meine Frage: "Wozu?".
TSherlockTimeSpan = type System.TimeSpan.TTimeSpan;
Sherlock |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz