DWORD-Cast unter XE2 x64

[MiKaEr]

hallo, folgende unit verwende ich, um auf änderungen im dateisystem zu reagieren:

http://www.cromis.net/blog/downloads/directory-watch/

diese funktioniert unter xe2 x86 sehr gut. unter x64 jedoch, erhalte ich einen fehler: der linken seite kann nichts zugewiesen werden.

Inc([B]Dword([/B]Notifydata), Nextentry); nun habe ich das etwas abgeändert und es funktioniert auch. meine frage ist nun aber: ist das so "in ordnung" oder sollte ich einen int64-cast nehmen statt pbyte?

Delphi-Quellcode:

{$IFDEF Win32]
Inc(Dword(Notifydata), Nextentry);
{$ELSE}
Inc([B]PByte([/B]Notifydata), Nextentry);
{$ENDIF}

einziger nachteil bei diesem neuen x64-konstrukt: meim formdestroy erhalte ich eine AV: FreeAndNil(FDirectoryWatch); . ist nun aber ERST EINMAL nicht weiter schlimm.

[DeddyH]

Notifydata := NotifyData + Nextentry; Müsste doch dasselbe tun, oder?

[edit] Ach, das ist ein Pointer, da dürfte das so nicht gehen. [/edit]

[himitsu]

Delphi-Quellcode:

// da irgendwer auf die saublöde Idee gekommen ist den Integer nicht mehrmitwachsen zu lassen :stupid:
{$IF Declared(NativeUInt)}
  Inc(NativeUInt(Notifydata), Nextentry);
{$ELSE}
  Inc(Cardinal(Notifydata), Nextentry);
{$IFEND}

// oder

Inc({$IF Declared(NativeInt)}NativeInt{$ELSE}Cardinal{$ENDIF}(Notifydata), Nextentry);

// oder

type // global deklariert
  Irgendwas = {$IF Declared(NativeUInt)}NativeInt{$ELSE}Cardinal{$ENDIF};

Inc(Irgendwas(Notifydata), Nextentry);

// oder

type  // macht man bei diesem Scheiß nicht mit, dann :twisted:
  {$IF Declared(NativeInt)}
    Integer  = NativeInt;
    Cardinal = NativeUInt;
  {$IFEND}

Inc(Cardinal(Notifydata), Nextentry);  // Pointer sind vorzeichenlos :zwinker:

// oder

Inc(LPARAM(Notifydata), Nextentry);  // weiß jetzt nicht direkt wo es deklariert ist (vermutlich Windows oder Messages)
// LPARAM/WPARAM/RPARAM würd für Konvertierungen bei SendMessages verwendet

// oder

Inc(PAnsiChar(Notifydata), Nextentry);  // PByte verfügt scheinbar nicht immer eine über Pointer-Arithmetik
// PChar/PAnsiChar/PWideChar verfügen aber über sowas und PAnsiChar rechnet immer mit 1

[Bernhard Geyer]

Zitat von himitsu:

// da irgendwer auf die saublöde Idee gekommen ist den Integer nicht mehrmitwachsen zu lassen

Gibts eigentlich eine relevante Programmiersprache in der der Integer unter 64-Bit auch 8 Byte lang ist?
Java, .NET, und AFAIK auch C++. Überall ist man zu dem Schluss gekommen das ein mitwachsender Integer mehr Probleme schafft als löst. Und damit schaft man endlich auch die Unsitte ab in einem Integer einen Pointer speichern zu wollen.

[MiKaEr]

genau, es ist ein Pointer.

keine ahnung warum; aber der folgende thread kann gelöscht werdn (doppelt): http://www.delphipraxis.net/166119-d...-new-post.html

funktioniet einwandfrei unter x64 und x86. doof ist nur, dass wenn man zwischen 32bit und 64bit "zielplattform" wechselt, dass man immer die DCUs löschen muss (versionsunterschied).

[Bernhard Geyer]

Zitat von MiKaEr:

doof ist nur, dass wenn man zwischen 32bit und 64bit "zielplattform" wechselt, dass man immer die DCUs löschen muss (versionsunterschied).

Definier mal DCU-Ausgabepfade für die unterschiedlichen Plattformen.

[himitsu]

Tja, Kompilerschalter werden nicht einbezogen, bei der Prüfung auf veränderte Units. (der Quellcode selber bleibt ja identisch ... wobei ich gehofft hab, Embarcadero bemerkt irgendwann mal dieses Problem )


Und nein, gibt es nicht (zumindestens nicht unter den großen/bekannten Programmiersprachen), also das mit dem Integer.
Das hat man sich wohl schon bei der Einführung der 64-Bit-CPUs überlegt und die Programmiersoftwarehersteller sind alle wie die Lämmer blind gefolgt.

[MiKaEr]

eine abschließende frage noch.

vor langer zeit hatte ich die trail-version von "xe", nun "xe2".

ist es normal, dass man ein extrem schlechtes gefühl im magen hat, bevor man xe2 nutzt, hat man doch vorher die super verbuggte xe-version genutzt?