string(Integer)

[Benmik]

Nachdem ich mit der Lösung aus diesem Thread viele Jahre ganz gut gefahren bin, habe ich dann doch mein Programm auf 64 Bit umgestellt. Zu meiner großen Verblüffung ging das vergleichsweise problemlos; da stecken eine Reihe von Komponenten drin, die doch recht betagt sind.

Dann beschwerte sich der Compiler an dieser Stelle:

Delphi-Quellcode:

procedure TPngImage.LoadFromResourceID(Instance: HInst; ResID: Integer);
begin
  LoadFromResourceName(Instance, string(ResID));
end;

string(ResID) ??! Man lernt ja nicht aus.

Nach Lektüre von

Delphi-Quellcode:

LoadFromResourceName

habe ich dann folgende Lösung gefunden:

Delphi-Quellcode:

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

Ich weiß aber noch nicht mal, ob das funktioniert. Wieso geht

Delphi-Quellcode:

string(ResID)

? Warum nicht mehr unter 64 Bit? Ist meine Lösung korrekt?

[hoika]

Hallo,
LoadFromResourceName war wohl unter 32Bit überladen (overload).

Update:
Bei mir ist es nicht überladen und der Typecast erzeugt einen Compiler-Fehler (ungültige Typumwandlung).

[Uwe Raabe]

Wieso compilierst du überhaupt TPngImage, wo das doch in Vcl.Imaging.pngimage bereits mitgeliefert wird?

[hoika]

Hallo,

Zitat:

da stecken eine Reihe von Komponenten drin

Weil er vielleicht erst mal Compilieren will und dann schrittweise Ersetzen...

[Benmik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1431672)

Wieso compilierst du überhaupt TPngImage, wo das doch in Vcl.Imaging.pngimage bereits mitgeliefert wird?

Die Antwort ist natürlich typisch für einen Amateur: Weil ich das Programm seit Jahren entwickle und viel herumexperimentiert habe, so dass offenbar noch irgendwelche Relikte herumliegen, die referenziert werden. Kann aber auch sein, dass ich eine Funktion aus einer Unit benutze, die TPngImage referenziert. Jedenfalls verwende ich gar keine PNG. Natürlich darf ich das nicht (man darf so vieles nicht!), aber ich vertraue darauf, dass der Compiler alles Unbenutzte wegoptimiert.

Ich bin aber recht sicher, dass du die Antworten auf meine Fragen weißt, möchtest du sie nicht geben?

[hoika]

Hallo,
dann benenn doch PngImage.pas um, dann Shift+F9 und schon meldet der Compiler die "verirrte" Unit ;)

Ich dachte, Du benutzt die Unit.
Interessant ist der typecast trotzdem.
aber ich glaube, dass da was Sinnvolles rauskommt

Delphi-Quellcode:

  i:= 100;
  MessageBox(0, PChar(String(i)), '', 0);

Zugriffsverletzung innerhalb der Windows-eigenen Dlls.
Ein harter Typecast mag den Compiler zufriedenstellen, aber ob zur Laufzeit was richtiges rauskommt ...

[Benmik]

Zitat:

Zitat von hoika (Beitrag 1431671)

Hallo,
LoadFromResourceName war wohl unter 32Bit überladen (overload).

Die Prozedur wird innerhalb der Unit aufgerufen:

Delphi-Quellcode:

procedure TPngImage.LoadFromResourceName(Instance: HInst; const Name: String);
var
  ResStream: TResourceStream;
begin
  try ResStream := TResourceStream.Create(Instance, Name, RT_RCDATA);
  except RaiseError(EPNGCouldNotLoadResource, EPNGCouldNotLoadResourceText);
  exit; end;
  try
    LoadFromStream(ResStream);
  finally
    ResStream.Free;
  end;
end;

Da ist nichts überladen.

[hoika]

Hallo,
ja, siehe mein voriger Post.

[Benmik]

Zitat:

Zitat von hoika (Beitrag 1431677)

Hallo, dann benenn doch PngImage.pas um, dann Shift+F9 und schon meldet der Compiler die "verirrte" Unit ;)

Wie gedacht, eine andere Komponente, die ich in der Tat benutze, referenziert PngImage.pas.

[hoika]

Hallo,
die Unit ausklammern?

[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.