Thanks for this new list. Diff like

- Result:=integer(PtrUInt(FCols[aCol]))
+ Result:=FCols[aCol]

shows it's useful. It supports Longint or PtrInt or PtrUInt? Or i need another list for PtrInt?

On Mon, Nov 13, 2017 at 7:58 PM, Alexey via Lazarus <

It supports Integer which means Longint.
You need another list for PtrInt but it is very easy to implement using generics as you can see from TIntegerList.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171113/55bea53c/attachment-0001.html>

  it is very easy to implement using generics as you can see from TIntegerList.

Good to include lists for [Int64, PtrInt, PtrUInt] to the same unit.

On 14 November 2017 at 01:58, Alexey via Lazarus <

You may already be aware, but check out the warnings in this page https://www.freepascal.org/docs-html/rtl/system/ptrint.html

"*The introduction of the ptrint type was a mistake. Please use ptruint <https://www.freepascal.org/docs-html/rtl/system/ptruint.html>** instead*"

Cheers

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171114/c27c2bf9/attachment.html>

That warning is misleading, makes too many assumptions about why the user needs to do something (often a common mistake when trying to "correct" others) and IMO wrong. Pointers and integers are separate things and a very common reason PtrInt and PtrUInt are used are to reserve memory in cases where you may want to store either an integer or a pointer but never both and need enough memory to hold either one (similar reason why intptr_t and uintptr_t exist in C). In that case, IntPtr is very useful when you want the integer to be signed.

For example, TComponent uses that for the Tag attribute and it is sometimes useful that you can store both unsigned integers and pointers in it.

Beyond that, it is also useful when interfacing with C code that accepts intptr_t (for the same reasons).

The warning is really like having a "warning: dont use this because it is dangerous" sticker to an industrial saw: the people buying the saw are already in a position to know what they need to use it.

Summary: the IntPtr type was far from a mistake, the warning is misleading and IMO it should be removed not only for the above reasons, but also because AFAIK not all platforms treat pointers as linear addresses (let alone signed or unsigned - for an example see i8086 pointers) and pointer arithmetic should be done with the pointer types themselves instead of converting them to integers (this is especially necessary for non-linear addresses since IntPtr(Ptr+1) might not be the same as IntPtr(Ptr)+1).

On Mon, Nov 13, 2017 at 8:16 PM, Michael Thompson via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171113/843791c8/attachment.html>

Alexey wrote

Good to include lists for [Int64, PtrInt, PtrUInt] to the same unit.

List of PtrInt or PtrUInt makes no sense. Those types are used only when casting to/from a Pointer which typically involves some ugly hack. The original type was wrong if you must cast it. A list of Int64 however makes sense. I will add it.

Juha