CopyFileEx und Codeoptimierung XE5

[wurzelzwerg]

Deine Version geht.

Das fliegt raus:

Delphi-Quellcode:

var
  Cancelled: Boolean;
begin
  if not CopyFileEx('d:\Neues Textdokument.txt',
      'd:\Neues Textdokument (Kopie).txt',
      nil, nil, @Cancelled,
      COPY_FILE_NO_BUFFERING
   )
   then RaiseLastOSError();

Jetzt komischerweise unabhängig von Code-Optimierung, also immer.


Im ursprünglichen Programm muss das @Cancelled raus und nil rein dann gehts auch dort.
Nur Warum?

[Uwe Raabe]

Die lokale Variable Cancelled wird nicht implizit initialisiert. Wenn da zufällig true drin steht, würde das CopyFileEx abbrechen. Selbst wenn du die vorher auf false setzt, wird der Compiler den Aufruf wegoptimieren, da die Variable später nicht ausgelesen wird. Offenbar wird die Übergabe an CopyFileEx über den Adressoperator nicht als Verwendung angesehen.

Versuch doch mal einfach nach dem CopyFileEx noch eine Abfrage auf Cancelled zu machen (natürlich so, daß die nicht auch noch wegoptimiert wird).

[Der schöne Günther]

Vielleicht würde Addr(Cancelled) statt @Cancelled einen Unterschied bzgl. Optimierung machen? (Ich rate nur wild)

[himitsu]

Ob und welches Cancelled := False; wegoptimiert wurde, müsste man nach dem Compilieren eigentlich sehen (die blauen Pünktchen) und auch der Debugger würde die Befehle entsprechend überspringen.

Zitat von Uwe Raabe:

(natürlich so, daß die nicht auch noch wegoptimiert wird).

Ist der Compiler eigentlich inzwischen so intelligent, daß er auch leere IFs erkennt?
Oder optimiert er if Cancelled then ; immernoch nicht weg?

[wurzelzwerg]

Hilft beides nicht.
Cancelled ist davor und danach false und CopyFileEx fliegt raus.

Delphi-Quellcode:

var
  Cancelled: Boolean;
begin
  Cancelled:= false;
  if not CopyFileEx('d:\Neues Textdokument.txt',
      'd:\Neues Textdokument (Kopie).txt',
      nil, nil, @Cancelled,
      COPY_FILE_NO_BUFFERING
   )
   then RaiseLastOSError();
   if Cancelled then
     beep;

[Union]

if CompilerVer > D2009 then LongBool <> Boolean;

[DeddyH]

War Boolean nicht immer schon ByteBool?

[Union]

Ja Aber in diesem Fall liegt es an den Variablen. Bei ausgeschalteter Optimierung belegt wohl das boolean eine Registerbreite. Ist sie angeschaltet dann wird nur noch ein Byte belegt. Jetzt wird ein Pointer auf die Adresse des boolean an die CopyFileEx übergeben. Dieses ist der festen Überzeugung das es 4 byte lesen muss und darf. Damit hängt der Inhalt aus Sicht der WinApi davon ab, was dahinter gerade so zufällig an den nächsten 3 byte im Speicher steht.

[wurzelzwerg]

Danke, das wars. Mit LongBool gehts.

[Christian Seehase]

Zitat von DeddyH:

War Boolean nicht immer schon ByteBool?

Bis D7 zurück auf jeden Fall.
(kleiner kann ich im moment nicht prüfen )