Hello
I found that Windows has some new Windows Data Types
DWORD_PTR, INT_PTR, LONG_PTR, UINT_PTR, ULONG_PTR
can you tell me when, how and why to use them?
Hello
I found that Windows has some new Windows Data Types
DWORD_PTR, INT_PTR, LONG_PTR, UINT_PTR, ULONG_PTR
can you tell me when, how and why to use them?
The *_PTR
types were added to the Windows API in order to support Win64's 64bit addressing.
Because 32bit APIs are used to store pointers to things using data types like DWORDS
, it was necessary to create new types for 64 bit compatibility that acted like a DWORD
in 32bits, but were extended to 64bits when used in a 64bit app.
So, for example, application developers who want to write code that works as 32bit OR 64bit the windows 32bit API SetWindowLong(HWND,int,LONG)
was changed to SetWindowLongPtr(HWND,int,LONG_PTR)`
In a 32bit build, SetWindowLongPtr
is simply a macro that resolves to SetWindowLong
, and LONG_PTR
is likewise a macro that resolves to LONG
.
In a 64bit build on the other hand, SetWindowLongPtr
is an API that accepts a 64bit long as its 3rd parameter, and ULONG_PTR
is typedef for unsigned __int64
.
By using these _PTR
types, one codebase can compile for both Win32 and Win64 targets.
When performing pointer arithmetic, these types should also be used in 32bit code that needs to be compatible with 64bit.
so, if you need to access an array with more than 4billion elements, you would need to use an INT_PTR rather than an INT
CHAR* pHuge = new CHAR[0x200000000]; // allocate 8 billion bytes
INT idx;
INT_PTR idx2;
pHuge[idx]; // can only access the 1st 4 billion elements.
pHuge[idx2]; // can access all 64bits of potential array space.
Chris Becke is pretty much correct. Its just worth noting that these _PTR types are just types that are 32-bits wide on a 32-bit app and 64-bits wide on a 64-bit app. Its as simple as that.
You could easily use __int3264 instead of INT_PTR for example.