Based on what the documentation says "introduction of ptrint type was a mistake", shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0 and removed in a later release like 3.0.2 or 3.2.0?

http://www.freepascal.org/docs-html/rtl/system/ptrint.html

Regards,
- Graeme -

PtrInt is sometimes used in this case:

TList stores arbitrary Pointers. To store an arbitrary integer you cast it with PtrInt.
Is there an integer list?

Mattias

I don't think it should be removed. It's more of a "if you use it, you must know what you're doing" type of thing IMO. It's useful for e.g. obtaining the result of a pointer difference or storing a signed offset relative to a memory address.

Nikolay

Indeed.

I didn't add this sentences in the docs, and I will remove them, and replace them with with a warning as suggested.

Michael.

Hmmm, PtrInt is used in that very useful method TApplication.QueueAsync Call. Could cause a lot of problems in Lazarus apps if it was removed now - or at least without a lot of planning and warning.

http://lazarus-ccr.sourceforge.net/docs/lcl/forms/tapplication.queueasynccall.html

Mattias Gaertner wrote

TList stores arbitrary Pointers. To store an arbitrary integer you cast it with PtrInt. Is there an integer list?

Generics? [warning: I know nothing about generics]

Good point either way - thanks for the example.

Regards,
- Graeme -

Tony Whyman wrote

PtrInt is used in that very useful method TApplication.QueueAsync Call.

Though I never used the QueueAsync() call myself, but looking at the declaration, shouldn't that data type be PtrUInt anyway? As far as I understand Data points to data in memory, which will always be an positive (unsigned) value, not so? Or does Mattias's example apply here too.

Regards,
- Graeme -

Mattias Gaertner wrote on Wed, 18 Mar 2015:

Or PtrUInt. The remark in the docs (which I didn't add, for the record) is specifically about the signed variant.

Jonas

It's one I tend to use a lot as it's a nice platform independent way scheduling processing in the next cycle round the message loop. The problem is not whether or not the parameter should be PtrInt or PtrUint, it is currently PtrInt and changing it means a lot of work for any application that uses it.

If this were the only instance then maybe the work could be justified - but PtrInt is used in about a dozen other places in the Forms module alone and throughout the LCL and FCL. For example:

TDataLink.DataEvent(Event: TDataEvent; Info: Ptrint) in the DB Module.

I can understand the argument that says it was a bad idea in the first place - but all the work and instability to get rid of it.... "Let sleeping PtrInt's lie" to paraphrase an old saying.

Tony Whyman wrote

problem is not whether or not the parameter should be PtrInt or PtrUint, it is currently PtrInt and changing it means a lot of work for any application that uses it.

If the data you pass in is always positive pointer addresses (I would assume this being the norm), then the change will not break any existing code.

But my assumptions have been wrong before. ;-)

Regards,
- Graeme -

It is arbitrary Data.
The passed method already contains an Object (data in memory). The Data is usually used as a state or index within the object. But it can also contain a pointer.

Mattias

QueueAsyncCall takes two arguments - a pointer to a method and data. The method declaration must be of the type:

TDataEvent = procedure (Data: PtrInt) of object;

My apps have loads of methods defined as above and would certainly fail to compile if the PtrInt type was replaced with Ptruint. At the minimum it would require a search and check through all source code to make sure that the signed type was not significant followed by a sed script to effect the change.

Just for interest, I did a find and grep on the lazarus LCL directory (.pas, .pp and .inc) files and found 837 lines on which PtrInt was present. The lazarus components directory has 474 instances.

Tony Whyman wrote

TDataEvent = procedure (Data: PtrInt) of object;

To me PtrUInt seems more appropriate.

-Michael