![]() |
AW: string(Integer)
Die Unit ist ja kein Problem, seit ich die Stelle in
Delphi-Quellcode:
geändert habe. Da ich nicht mit PNG arbeite, wird die Stelle nie aufgerufen und ich weiß daher nicht, ob mein Ansatz richtig ist.
LoadFromResourceName(Instance, '#' + IntToStr(ResID));
Ich habe daher aktuell auch kein Problem, ich würde nur gern verstehen und hätte gern eine Antwort auf meine Fragen. |
AW: string(Integer)
Hallo,
ich würde gern verstehen, warum der alte Code compiliert werden konnte. Zitat:
|
AW: string(Integer)
Zitat:
![]() 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. |
AW: string(Integer)
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. |
AW: string(Integer)
Zitat:
Delphi-Quellcode:
ist ein
String
Delphi-Quellcode:
+ Referenzzähler + Länge + Elementgröße + Codepage + Terminus (
PChar
Delphi-Quellcode:
).
#0
Da ein
Delphi-Quellcode:
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
PChar
Delphi-Quellcode:
) speichern. Du kannst ja sonst auch
ResID
Delphi-Quellcode:
zu
Integer
Delphi-Quellcode:
casten, ohne dass der Compiler rummeckert.
Int64
Deshalb geht unter 64-Bit, genau wie unter 32-Bit:
Delphi-Quellcode:
. Das gleiche mit
PChar(MyInteger)
Delphi-Quellcode:
geht zwar nicht, allerdings kannst du das über einen Doppelcast machen:
String
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:
(bzw.
NativeInt
Delphi-Quellcode:
für die vorzeichenlose Entsprechung), oder, speziell für diesen Fall:
NativeUInt
Delphi-Quellcode:
.
IntPtr
Wenn du mit der Windows-API arbeitest, hast du hier wiederrum das Alias:
Delphi-Quellcode:
, was nichts anderes ist. Auch diese beiden Typen haben wiederrum eine unsignierte Form mit jeweils einem "U" vor dem Namen.
INT_PTR
Außerdem musst du halt grundsätzlich sehr vorsichtig mit dem
Delphi-Quellcode:
/
String
Delphi-Quellcode:
casten sein, denn:
Integer
Auch bringst du die Type-Info durcheinander, denn
Delphi-Quellcode:
ergibt immernoch
TypeInfo(String(MyInteger))
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. ;) |
AW: string(Integer)
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:47 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz