[Gelöst] Casting TObject zu Integer funktioniert nicht.

[kirchfritz]

Kann mir mal jemand erklären warum der Sourcecode meines Minimalprojects nicht mehr funktioniert:

Code: Alles auswählen

program Project1;
 
{$mode objfpc}{$H+}
 
uses
  Classes;
 
var
  sl : TStringList;
  i : integer;
 
begin
  sl := TStringList.create;
  with sl do
  begin
    Clear;
    AddObject('hello', TObject(1));
    AddObject('in', TObject(2));
    AddObject('there', TObject(3));
  end;
  for i := 0 to sl.Count - 1 do
  begin
    writeln(integer(sl.Objects[i]));
  end;
  sl.Free;
end.
 

Bei der Writeln Anweisung kommt als Fehlermeldung:

Code: Alles auswählen

Error illegal type conversion from TObject to LongInt

Das hat bei mir immer funktioniert, aber seit dem Umstieg auf Lazarus 1.8 und damit auf FPC 3.0.4 geht das irgendwie nicht mehr.
Hat irgendjemand eine Idee, was da bei mir falsch läuft?

Für Eure Hilfe wäre ich sehr dankbar.
Fritz

[theo]

Probier das: https://www.freepascal.org/docs-html/rt ... ruint.html

[mse]

Kann mir mal jemand erklären warum der Sourcecode meines Minimalprojects nicht mehr funktioniert:

Weil du vielleicht auf 64 bit gewechselt bist. pointer (64bit) ist nicht mehr mit integer(32bit) kompatibel.

Code: Alles auswählen

 
  for i := 0 to sl.Count - 1 do
  begin
   writeln(ptrint(sl.Objects[i]));
  end;
 

[kirchfritz]

Danke mse, Danke theo,

in leichter Abwandlung funktioniert 's jetzt

Code: Alles auswählen

program Project1;
 
{$mode objfpc}{$H+}
 
uses
  Classes;
 
var
  sl : TStringList;
  i : Qword;
begin
  sl := TStringList.create;
  with sl do
  begin
    Clear;
    i := 1;
    AddObject('hello', TObject(i));
    i := 2;
    AddObject('in', TObject(i));
    i := 3;
    AddObject('there', TObject(i));
  end;
  for i := 0 to sl.Count - 1 do
  begin
    writeln(PtrInt(sl.Objects[i]));
  end;
  sl.Free;
end.
 

Für alle, die diesen Beitrag später mal lesen sollten:
Wichtig ist, dass die Variable i vom Type QWord ist und die Writeln-Anweisung das Casting mit PtrInt macht.

[theo]

@kirchfritz, mse: Warum nicht den von mir vorgeschlagenen PtrUInt?
Was soll ein vorzeichenbehafteter Typ bei einem Pointer?

Ptrint is considered harmfull and should almost never be used in actual code, because pointers are normally unsigned.

https://www.freepascal.org/docs-html/rt ... trint.html

[m.fuchs]

Darf ich dir auch noch eine Variante zeigen, die ganz ohne missbräuchlichem Cast auskommt?

Code: Alles auswählen

program Project1;
{$MODE ObjFpc}
{$H+}
 
uses
  Classes, SysUtils, Fgl;
 
type
  TStringIntegerMap = specialize TFPGMap<String, Integer>;
 
var
  Map: TStringIntegerMap;
  i: Integer;
 
begin
  Map := TStringIntegerMap.Create;
  Map.Clear;
  Map.Add('hello', 1);
  Map.Add('in', 2);
  Map.Add('there', 3);
  for i := 0 to Map.Count - 1 do begin
    WriteLn(Map.Data[i]);
  end;
  FreeAndNil(Map);
end.      

[Mathias]

Für was wird AddObjects gebraucht ?
Ist dies zum durchnummerieren der einzelnen Stringeinträge ?

[mse]

@kirchfritz, mse: Warum nicht den von mir vorgeschlagenen PtrUInt?

Um eine integer in einem pointer zu speichern ist ptrint der geeignete Typ.
Um eine cardinal in einem pointer zu speichern ist ptruint der geeignete Typ.

[af0815]

Um eine integer in einem pointer zu speichern ist ptrint der geeignete Typ.
Um eine cardinal in einem pointer zu speichern ist ptuint der geeignete Typ.

Zu meinem Verständnis - müsste man genaugenommen nicht den Integer/Cardinal/... mit Boxing und Unboxing behandeln (=ein Objekt daraus machen) damit ist entsprechend sicher ist und auch auf den verschiedenen Plattformen arbeitet ist ?! Weil hier ist man ja ansonsten IMHO Plattformabhängig.


Andreas

[mse]

Ich glaube nicht. Die Bit-Grössen von integer/cardinal sind immer <= Bit-Grösse von pointer.

[kupferstecher]

@kirchfritz, mse: Warum nicht den von mir vorgeschlagenen PtrUInt?
Was soll ein vorzeichenbehafteter Typ bei einem Pointer?

Ptrint is considered harmfull and should almost never be used in actual code, because pointers are normally unsigned.

Zum Beispiel bei PostMessage wird als Argument für WParam und LParam ein PtrInt erwartet.
Was würde passieren, wenn man aber auf PtrUInt castet? Kompilieren tut es zumindest.
Und was kann passieren, wenn man auf Ptrint castet, in Fällen wo PtrUInt erwartet wird?

[theo]

@kirchfritz, mse: Warum nicht den von mir vorgeschlagenen PtrUInt?
Was soll ein vorzeichenbehafteter Typ bei einem Pointer?

Ptrint is considered harmfull and should almost never be used in actual code, because pointers are normally unsigned.

Zum Beispiel bei PostMessage wird als Argument für WParam und LParam ein PtrInt erwartet.
Was würde passieren, wenn man aber auf PtrUInt castet? Kompilieren tut es zumindest.
Und was kann passieren, wenn man auf Ptrint castet, in Fällen wo PtrUInt erwartet wird?

"Harmful" heißt in diesem Falle mMn nicht, dass etwas in die Hose gehen muss, aber du musst einfach ganz genau wissen was du tust. Wie bei Assembler o.ä.

[kupferstecher]

Mir geht es darum, was überhaupt passieren kann.

Ich hab mir angeschaut, was herauskommt, wenn man eine uInt8 (Byte) mit dem Wert $FF auf Int8 castet, das Ergebnis ist -1. Soweit so klar, aber auch über eine Zuweisung kommt das gleiche Ergebnis raus. In die andere Richtung von Int8 auf uInt8 kommt wieder $FF heraus, sowohl beim casten als auch über eine Zuweisung. D.h. das Vorzeichen beschädigt nicht das Bitmuster. Für den Anwendungsfall dass eine Bibliothek einen Pointer per Integer oder Unsigned erwartet, wäre es also erstmal egal, ob man per ptrInt oder ptrUInt castet.

Dann gäbe es noch den Fall, dass man Adressen berechnen möchte (Arrays etc.). Aber auch dort wandelt man ja nach erfolgter Berechnung wieder in einen Pointer um, es ist also wieder nur das Bitmuster entscheidend.