Erklärung zu Compiler-Hinweis?

[HJay]

Ich stelle gerade ein projekt von Delphi 6 auf Delphi 2010 um.

In einer eigenen, kurzen Unit verwende ich:

Code:

uses Forms, SysUtils;

initialization

DeleteFile(LogFile);

Der Compiler gibt den folgenden Hinweis aus: "H2443 Inline-Funktion "DeleteFile" wurde nicht expandiert, weil Unit 'Windows' in der USES-Liste nicht angegeben ist."

Was soll dieser Hinweis bedeuten? DeleteFile stammt aus SysUtils und nimmt ein String-Argument. Alles klappt, wie es soll. Warum kümmert sich der Compiler darum, dass es in der Unit Windows möglicherweise eine ähnliche lautende Prozedur gibt?

Sind die Prozeduren funktionell gleichwertig? Ich habe immer die aus SysUtils verwendet. Hat eine Vorteile gegenüber der anderen?

Die Prozedur Windows.DeleteFile nimmt ein PChar-Argument, was ich ja eigentloich auch blöde finde. Was spricht dagegen, bei SysUtils.DeleteFile zu bleiben?

Was soll der Hinweise? Muss ich ihn beachten?

[mkinzler]

Gib den Namespace mit an
SysUtils.DeleteFile(LogFile);

[himitsu]

Was es bedeuten soll steht ja eigentlich ganz genau da.

DeleteFile ist als Inline-Funktion deklariert, also es wird nicht die Funktion aufgerufen, sondern ihr Inhalt wird (wenn möglich) vom Compiler direkt an der Stelle eingebaut, wo du sie aufrufst.

Inline kann aber natürlich nur funktionieren, wenn das, was innerhalb der Funktion aufgerufen/verwendet wird, auch an der Stelle des Funktionsaufrufs verfügbar ist.

Bei dir ist es das nicht, da du kein "Windows" in deinen Uses hast.
Darum wird die Funktion eben "nur" direkt aufgerufen und Delphi sagt dir das, damit du dich nicht wunderst, weil man ja erwarten müßte, daß es Inline ist.

Schlimm isses nicht ... kann man ignorieren ... oder man nimmt die genannte Unit einfach auf.


mkinzler hat auch noch einen Grund genannt.
Ohne Namespace wird das genommen, was als Letztes über die Uses eingebunden wurde.

Gleichwertig ... fast, denn bei dir ist das SysUtils.DeleteFile nur eine Weiterleitung zu Windows.DeleteFile (DeleteFile, mit einem etwas anderem Parameter, wo man sleber nicht casten muß).
Seit Multiplattform aber nein, denn da wird automatisch, entsprechend von der Zielplattform, die passende "Dateilöschen"-API des Zielsystems aufgerufen.
In Linux, Mac und Co. gibt es ja keine WinAPI.

[HJay]

Danke für die Erläuterungen!

Ich habe jetzt Windows als erste Unit in die USES-Liste aufgenommen und der Compiler nimmt daher jetzt DeleteFile ohne zu Murren, wohl aus der SysUtils.

[himitsu]

Kannte D6 schon Code Insight?
Halte mal die Maus über DeleteFile und warte auf einen Hint. (falls er kommt)
Da steht dann drin, was genommen wird.

Und da du die VCL/RTL-Quellcodes besitzt ... Strg+Linksklick auf die Funktion und man landet bei deren Deklaration. (oder Kontextmenü > Deklaration suchen)

[HJay]

Nochmal danke, ja, den Bubble-Hint kenne ich. D6 hat automatisch SysUtils ausgewählt und D2010 wählt dank richtiger USES-Deklaration auch SysUtils aus. Bei vertauschter USES-Deklaration wählt es Windows.Deletefile aus.

Was mich nur grwundert hatte, war, dass wenn nur (!) SysUtils deklariert sind, dennoch das Meckern über die inline-Sache erfolgt. Falls SysUtils wirklich auf die unit Windows verweist, müsste das dortige USES doch alles erledigen? Na egal, ich führe unit Windows mit auf und fertig.

[himitsu]

Zitat von HJay:

Was mich nur grwundert hatte, war, dass wenn nur (!) SysUtils deklariert sind, dennoch das Meckern über die inline-Sache erfolgt.

Das hatte ich aber erklärt.

Das meckern kommt nicht, wenn/weil man beides eingebunden hat ... das wirkt sich nur darauf aus, was letztendlich "zuerst" genommen wird.
Ist aber Beides eingebunden und SysUtils als letztes, dann wird SysUtils.DeleteFile verwendet und das leitet dann an Windows.DeleteFile weiter.

Zitat:

Delphi-Quellcode:

function DeleteFile(const FileName: string): Boolean; inline;


function DeleteFile(const FileName: string): Boolean;
{$IFDEF MSWINDOWS}
begin
  Result := Windows.DeleteFile(PChar(FileName));
  ...

SysUtils.DeleteFile ist als inline deklariert.

Der Compiler würde daher gern den internen "Windows.DeleteFile"-Aufruf in deine Unit verlagern,
was aber nicht geht, weil bei dir kein Windows eingebunden ist ... daher der Hinweis.



Hinweis - nix Schlimmes, wollt's nur mal erwähnt haben
Warnung - hey du, da solltest du besser mal aufpassen
Fehler - ich mecker schonmal, mach aber noch ein bissl weiter (bis zum Unitende)
Schwerer Fehler - das mag ich nun überhaupt nicht *streik*

[Popov]

Zitat von himitsu:

Ohne Namespace wird das genommen, was als Letztes über die Uses eingebunden wurde.

Bist du sicher? Ich war immer der Meinung, dass das beachtet wird was zuerst in der Unit steht. Und wenn ich die paar Male bedenke die ich bisher mit dem Problem zu tun hatte, schien die Regel zu stimmen.

Das scheint mal wieder eines von diesen Regeln zu sein: "so funktioniert es nicht, aber keiner hat es dem Compiler mitgeteilt, also funktionierte es".

[DeddyH]

Das lässt sich doch ganz einfach ausprobieren: 2 Units, die eine gleichlautende Routine aufweisen. Nun bindet man beide ein und schaut, welche beim Aufruf genommen wird. Siehe da, es ist die aus der zuletzt eingebundenen Unit.

[himitsu]

Das Zuletzteingebundene ist näher beim Code der Unit
und in den Scopes wird immer vom Nächsten zum Entferntesten gesucht,
also wird immer das Letzte gefunden.

Ist genauso wie mit den Variablen.
Die lokalen wurden, in Bezug auf den Scope, zuletzt deklariert und werden zuerst gefunden.


Quasi ein Stack.