Merkwürde Warnings beim Compilieren von Befehlszeile

[AWeber]

Hallo,

ich habe derzeit einige Warnings, wo ich nicht weiterkomme durch was diese verursacht werden. In der IDE erhalte ich diese seltsamerweise nicht, aber sobald ich das Projekt via Makefile oder via Test Batchdatei und dcc32.exe übersetze erhalten ich folgende Warnings.

Warnung: W1072 Bei impliziter Konvertierung könnten signifikante Ziffern von 'Int64' bis 'Cardinal' verlorengehen
bei einem System.Math.max Aufruf -

Code:

CardinalVariable := system.Math.Max( 100, CardinalVariable );

sieht so aus als würde er die überladene Variante von Math.Max() mit int64 compilieren nur warum?

Warnung: W1072 Bei impliziter Konvertierung könnten signifikante Ziffern von '64-Bit-Integerwert mit Vorzeichen' bis 'Cardinal' verlorengehen

Code:

val( '932', newCardinalValue, code );

dito - warum int64 und keine Variante für Cardinal?

Warnung: W1048 Unsichere Typumwandlung von 'TSampleclass' nach 'Pointer'

Code:

with ctrl.Canvas do 
begin
  Draw(...)
end;

Das Warning kommt für den Kopf der with ... do Anweisung. Für alle Fälle wo sich das with scheinbar auf ein Property einer Klasse bezieht.

Hat jemand eine Idee - was diese Verhalten auslösen könnte?
Ich habe mal ein lleines Testprojekt + Compiler Aufruf CMD angehangen - vielleicht liegt es ja an den Parametern beim Aufruf des Compilers?

André

[himitsu]

Max gibt es nicht als Unsigned (Cardinal/LongWord).

Es wird also nicht das Max mit Integer sondern mit Int64 genommen, weil UInt32 nicht in Int32 rein passt. (Bits ja, aber nicht vom Wertebereich)

Und das Int64-Result vom Max passt dann nicht mehr komplett ins

Delphi-Quellcode:

CardinalVariable :=

rein, also kommt die Meldung. (obwohl es von den verwendeten, bzw. logisch möglichen Werten schon passen würde)
Lösung: ein expliziter Cast

Delphi-Quellcode:

 := Cardinal(Max(...))

Und Nein, VAL gibt es ebenfalls nicht "explizit" für Cardinal.

Zitat:

Zitat von Auszug aus der System.pas

Delphi-Quellcode:

function _ValLong(const S: string; var Code: Integer): Integer;
function _ValExt(s: string; var code: Integer): Extended;
function _ValInt64(const S: string; var Code: Integer): Int64;
function _ValUInt64(const s: string; var code: Integer): UInt64;

Wertest du auch "code" aus?
Wenn nicht, warum verwendest du dann diese "uralten" Pascalfuktionen, anstatt TryStrToInt/TryStrToInt64 bzw. StrToIntDef
oder die neuen Helper ala TCardinalHelper.Parse? (

Delphi-Quellcode:

newCardinalValue := Cardinal.Parse('932');

)

Im TStringHelper gibt es zwar auch nur ToInt64 (für Cardinal), also dort ebenfalls mit Cast

Delphi-Quellcode:

C := Cardinal('932'.ToInt64);

, wie beim StrToInt64.

[AWeber]

Hallo,

ja val() ist alt, mag sein - aber da der Code auch so alt ist ;) und immerschön auf Code geachtet wird, sehe ich da auch keinen Grund ranzufassen.
Was mich halt sehr verwundert, warum die Warnings nur beim Compilieren mit Befehlszeile auftreten - und in der IDE scheinbar sich per Vorgabe Delphi nicht daran stört?

Das es die Funktionen für Cardinal nicht direkt gibt, habe ich in System.Math.pas mittlerweile auch gesehen, aber nicht immer hat das ja was zu bedeuten,
wenn da evtl. doch eine gewisse Compiler Magic bei einigen Funktionen dabei ist.


André

[himitsu]

Welche Delphi-Version?

Inline-Compiler und Commandline-Compiler könnten sich schon bissl unterschiedlich verhalten.
Oder du Kompilierst einfach mit unterschiedlichen Optionen.

In neueren Delphis mit den DPROJ kann man auch die DPROJ über MSBUILD statt "direkt" der DPR über DCC32 kompilieren.
Beim DCC kannst ja andere Optionen angeben (oder es vergessen), als in den Projektoptionen im Delphi eingestellt.
Über DPROJ+MSBUILD kann man genau mit den "selben" ProjektOptionen kompilieren.

Zitat:

aber nicht immer hat das ja was zu bedeuten

Eher andersrum.

Was in der Math.pas drin ist, das ist auch genau so da auch drin.

Es kann maximal sein, dass es noch wo anders überladene Funktionen gibt.
z.B. in SysUtils ist Einiges, was auch in der StrUtils oder Math drin ist und dann gibt es auch noch die AnsiStrings (neben der SysUtils und Strutils).

Aber das in der System.pas ... nicht alles was das CodeInsight als dort drin anzeigt, dass ist wirklich dort drin und es muß nicht gleich heißen. (die liebe CompilerMagic)

[AWeber]

Hallo,

ich verwende hier Delphi 10.4.1 Professional, die DCC32.exe bekommt nur das DPR zu sehen, im selben Ordner gibt es kein DPROJ oder dergleichen, d.h. alle Parameter / Optionen sollten eigentlich nur von der Befehlszeile kommen. (siehe auch compile.cmd im Beispiel vom Anfang)

André

[himitsu]

Da du keine DPROJ hast, wird Delphi beim Öffnen in der IDE eine Dafaultversion dafür erstellen.
Und vermutlich hat die andere Optionen, als du deinem DCC32 gegeben hast und schon kommt da auch was Anderes bei raus.

Diese einfach mal behalten und nicht löschen, dann kannst sie auch zum Kompilieren verwenden.

Code:

:: zuletzt installiertes Delphi nehmen und damit kompileren (mit aktiver Platform und Config aus der DPROJ)
call rsvars.bat
msbuild minmax.dproj
if errorlevel 1 pause

:: oder explizit call "%ProgramFiles(x86)%\Embarcadero\Studio\21.0\bin\rsvars.bat"
:: oder msbuild /nologo /target:Build /p:config=Debug;Platform=Win32 minmax.dproj
:: und man kann sogar eine ganze .groupproj reingeben (denn die ist eigentlich auch ein MSBuild-Script)

Die rsvars.bat kannst auch für den DCC32 als Ersatz für dein SET verwenden.

[himitsu]

Insgesamt ist es über MSBuild praktischer (seit jetzt 10.4.2 startet der Delphi-Installer sogar das Setup vom Windows SDK, falls es noch nicht installiert ist).
So hat man auch über Console oder IDE immer die selbe Ausgabe. (außer man hat so kranke IDE-Extensions, wie z.B. Eurekalog, welche sich IMHO falsch integrieren, so dass sie im MSBuild fehlen)

Die DCC*.exe und RC.exe/BRCC.exe braucht man eigentlich nur noch, wenn man manuell direkt PAS zu DCU oder RC zu RES kompilieren will, ohne es über ein Delphi-Projekt (dpr/dproj) erledigen zu lassen.