Illegal conversion from Integer to TObject on 64 bit Lucid

[br4d]

Hi guys,

I have troubles in compiling a project with following message:

Error: Illegal type conversion: "LongInt" to "TObject"

I do know that this error can be fixed if I change the variable declaration from Integer to Int64.

But the problem is: this project is currently being developed on various systems (32 and 64 bits).
Can I just specify a flag to tell the compiler to handle all integer as 32 bit?

I have googled for some hours but can't find any clue to make it compiled with little changes.
 
Sorry for my bad English and thanks.

[Leledumbo]

I do know that this error can be fixed if I change the variable declaration from Integer to Int64.

I won't call it a fix, but a hack. Post the relevant code here, what is the expression trying to do by converting integers to tobject?

[br4d]

The conversion comes in various units. Some of them try simply to store an integer into a stringlist (as an indexed object).

[Leledumbo]

I know it's a bit overkill to create a class that only has 1 integer property, but that's the better way to store it inside TStringList. As an alternative, you might want to try TFPGMap<String,Integer> from fgl unit though you'll lose TStringList specific methods.

[br4d]

Thanks Leledumbo, but as I wrote previously, the project is currently developed by multiple persons. And I dont want to change codes written by others.
Probably the most simple solution is to install lazarus 32 bit and its corresponding fpc 32 bit. But not sure if it can run without complication on 64 bit Lucid. In worst case simply install Lucid 32 bit.

[br4d]

The conversion comes in various units. Some of them try simply to store an integer into a stringlist (as an indexed object).

Sorry I was in wrong Programming Languange Concept. The statement above wont work as a casting of TObject(AnInteger) will give me an object at the ADDRESS of AnInteger. And not an Integer Object with that value, because FPC dont treat Integer as object.

[Leledumbo]

Thanks Leledumbo, but as I wrote previously, the project is currently developed by multiple persons. And I dont want to change codes written by others.

Well you could tell the other member who wrote the code about my suggestion.

Sorry I was in wrong Programming Languange Concept. The statement above wont work as a casting of TObject(AnInteger) will give me an object at the ADDRESS of AnInteger. And not an Integer Object with that value, because FPC dont treat Integer as object.

Indeed, that's why I said it was a hack. If you insist however, don't use Integer, use PtrInt or PtrUInt instead. It's the processor's native pointer size.

[br4d]

As now it became clear to me that this way of programming is dirty, I'll tell the dev-team to clean their codes. Thanks Leledumbo.
 
IMHO this should be banned from FPC, and using different approach of acquiring object's address like on others prog. languange.

[Leledumbo]

IMHO this should be banned from FPC, and using different approach of acquiring object's address like on others prog. languange.

If Delphi allows it, FPC would probably do as well for compatibility reason. Casting is indeed one of evils ported from C, though it's a little better in Object Pascal. It has its use, but the programmer's responsibility is higher here. Often, you could find this piece of Delphi code:

Code: [Select]

Integer(Pointer(SomeVariable))and it's useful to calculate offsets as integers.

[br4d]

Code: [Select]

Integer(Pointer(SomeVariable))and it's useful to calculate offsets as integers.

Agree, but your example above explains very clearly the reason we do the casting (probably memory address manipulation like on array operation, etc).
But not if somebody do this:
myInteger:= integer(myObject); //acquire address of myObject

and later to retrieve the object
myObject:= TObject(myInteger);

Your example will probably run well on 32 or 64 bit OS. But my example has caused me the initial trouble in this thread.
And that is what I think should be banned from FPC.

[Laksen]

Agree, but your example above explains very clearly the reason we do the casting (probably memory address manipulation like on array operation, etc).
But not if somebody do this:
myInteger:= integer(myObject); //acquire address of myObject

and later to retrieve the object
myObject:= TObject(myInteger);

Your example will probably run well on 32 or 64 bit OS. But my example has caused me the initial trouble in this thread.
And that is what I think should be banned from FPC.

It'll not run on a 64bit platform. Integer is a bad type, if you aren't careful it might even be 16bit

Always use PtrUInt when dealing with pointers cast to an integer type.