string(Integer)

[Benmik]

Die Unit ist ja kein Problem, seit ich die Stelle in

Delphi-Quellcode:

LoadFromResourceName(Instance, '#' + IntToStr(ResID));

geändert habe. Da ich nicht mit PNG arbeite, wird die Stelle nie aufgerufen und ich weiß daher nicht, ob mein Ansatz richtig ist.

Ich habe daher aktuell auch kein Problem, ich würde nur gern verstehen und hätte gern eine Antwort auf meine Fragen.

[hoika]

Hallo,
ich würde gern verstehen,
warum der alte Code compiliert werden konnte.

Zitat:

und ich weiß daher nicht, ob mein Ansatz richtig ist

Das ist halt die Frage.

[Uwe Raabe]

Zitat:

Zitat von Benmik (Beitrag 1431688)

Ich habe daher aktuell auch kein Problem, ich würde nur gern verstehen und hätte gern eine Antwort auf meine Fragen.

Also: Der Parameter Name von LoadFromResourceName landet am Ende als PChar-Cast bei einem Aufruf von FindResource. In der Beschreibung zu FindResource steht, daß alternativ zu einem Pointer auf einen String auch eine mittels MakeIntResource gewandelte ID eines Resource-Types dort stehen kann. Windows entscheidet das ganz einfach danach, ob der übergebene Pointer in den höheren 16 Bit alles Nullen stehen hat. Da die gültigen Resource-Typen dieses Kriterium per geeigneter Definition erfüllen und String-Pointer eher nicht, stellt das offenbar auch kein Problem dar.

Der Cast string(<Integer>) ist also nur ein syntaktischer Trick für einen Cast PChar(<Integer>), weil der Compiler sonst meckern würde.

Nun kann man unter x86 ja problemlos einen Integer -> Pointer Cast machen, da beide als 32 Bit Wert gespeichert werden. In x64 ist das nicht mehr so. Dort belegen Pointer 64 Bit und ein Cast á la Pointer(<Integer>), PChar(<Integer>) und somit auch string(<Integer>) wird vom Compiler korrekterweise zurückgewiesen.

Übrigens, du solltest die PngImage Unit (und auch die pngzlib, pnglang und das dazugehörige obj-Verzeichnis) tatsächlich einfach löschen (oder wenigstens den Suchpfad darauf entfernen) und die mitgelieferte verwenden. Da du sie ja nicht brauchst, kann dir ja auch nichts passieren, und solltest du sie doch mal brauchen, würde sie vermutlich gar nicht mal funktionieren.

[Benmik]

Mann, Uwe, du hast wirklich ein Wissen angesammelt, du meine Güte.
Vielen Dank für die Erhellung. Keine Chance, auf sowas allein zu kommen.

[Dennis07]

Zitat:

Zitat von Benmik (Beitrag 1431669)

Wieso geht

Delphi-Quellcode:

string(ResID)

?

Delphi-Quellcode:

String

ist ein

Delphi-Quellcode:

PChar

+ Referenzzähler + Länge + Elementgröße + Codepage + Terminus (

Delphi-Quellcode:

#0

).
Da ein

Delphi-Quellcode:

PChar

ein Zeiger ist und dieser unter 64-Bit eine Größe von 64 Bit hat, kannst du in ihm also ohne Probleme eine 32-Bit-Zahl (wie in dem Beispiel

Delphi-Quellcode:

ResID

) speichern. Du kannst ja sonst auch

Delphi-Quellcode:

Integer

zu

Delphi-Quellcode:

Int64

casten, ohne dass der Compiler rummeckert.
Deshalb geht unter 64-Bit, genau wie unter 32-Bit:

Delphi-Quellcode:

PChar(MyInteger)

. Das gleiche mit

Delphi-Quellcode:

String

geht zwar nicht, allerdings kannst du das über einen Doppelcast machen:

Delphi-Quellcode:

String(PChar(MyInteger))

.

Grundsätzlich solltest du dies aber vermeiden, da es andersherum nur mit ggf. einem Datenverlust funktionert. Für so etwas hast du unter allen Plattformen das Alias

Delphi-Quellcode:

NativeInt

(bzw.

Delphi-Quellcode:

NativeUInt

für die vorzeichenlose Entsprechung), oder, speziell für diesen Fall:

Delphi-Quellcode:

IntPtr

.
Wenn du mit der Windows-API arbeitest, hast du hier wiederrum das Alias:

Delphi-Quellcode:

INT_PTR

, was nichts anderes ist. Auch diese beiden Typen haben wiederrum eine unsignierte Form mit jeweils einem "U" vor dem Namen.

Außerdem musst du halt grundsätzlich sehr vorsichtig mit dem

Delphi-Quellcode:

String

/

Delphi-Quellcode:

Integer

casten sein, denn:

• beim Kopieren des
  Delphi-Quellcode:

  Integer

  s wird das ganze andere, wie die Länge und Referenzzählung nicht mit kopiert. Es kann also zu Datenverlust führen.
• Der Referenzzähler funktioniert nur, wenn die Variable den Typen
  Delphi-Quellcode:

  String

  hat. Es kann also sein, dass dieser einfach freigegeben wird, weil das System denkt, dass du ihn nicht mehr benötigst.
• Das Aufrufen von bspw.
  Delphi-Quellcode:

  Length(String(MyInteger))

  kann zu Zugriffsverletzungen führen.

Auch bringst du die Type-Info durcheinander, denn

Delphi-Quellcode:

TypeInfo(String(MyInteger))

ergibt immernoch

Delphi-Quellcode:

TypeInfo(Integer)

.

Ich hoffe das war jetzt nicht zu ausführlich. Aber du wolltest wissen, warum es geht und was 64-Bit da für auswirkungen drauf hat. ;)

[Benmik]

Auch eine schöne und lehrreiche Antwort, vielen Dank!

PS: Wenn der Compiler bei der Umwandlung zu 64 Bit gemeckert hat, dann hat es in aller Regel ausgereicht, LongInt durch NativeInt zu ersetzen. Das hätte ich mir alles viel schlimmer vorgestellt, vor allem bei den API-Aufrufen.