INT_PTR to int

[the one]

Hi,

I'm trying to adopt my [VC++ 6.0] code to [.NET C++]...

There is some changes in MFC.
One of them is return types!.. e.g.

CList::GetCount() returns int in 6.0, but
it returns INT_PTR in .NET

I still use it as 'int' ...
INT_PTR sounds like 'a pointer to an int'. Therefore it seems
"the count of elements in list" = *m_List.GetCount(); // with de-reference
However, it works without 'de-referencing' !

Could you please explaine what is going around and what does Microsoft want to do?

Thanks...

[Ness]

INT_PTR and int are EXACTLY the same. You can change 'em, move 'em, allocate 'em, or any other fun thing you do with int.

"Uhh ohh, one of the functions require int, but I only have INT_PTR"
TheFunctionThatUsesIntInsteadOfINT_PTR(..., (int)The VariableThatUsesINT_PTR)

(int)TheFunctionThatReturnsINT_PTR(...)

Self explanitory, man.

[JasonD]

To better explain, take a look at the following page:
Windows Data Types

INT_PTR was created as a solution to the problem of the eventual need for code to compile correctly on both 32-bit and 64-bit compilers simultaneously. It was one of a few data types that were created in this solution. If you'll look at the above page, you'll see that it is defined like so:

#if defined(_WIN64)
typedef __int64 INT_PTR;
#else
typedef int INT_PTR;

_WIN64 is defined when you are compiling for 64-bit Windows. So, the size of the value is 32-bits for 32-bit Windows, and 64-bits for 64-bit Windows.

What is the reason for this? The main problem is that of pointers - they are 32-bits in size for 32-bit Windows, and 64-bits for 64-bit Windows. Since pointers, and a lot of Windows data types (like handles) which are actually pointers, require that they change size going from 32 to 64-bit Windows, you need to be able to define your own variables that do the same. INT_PTR is one of them. When you need to do pointer arithmetic, you need a variable that is the same size. The above page states for INT_PTR:
"Signed integral type for pointer precision. Use when casting a pointer to an integer to perform pointer arithmetic."
This is exactly what it is for. Using an int in 64-bit windows for pointer arithmetic will run you into trouble, because it will likely be only 32-bits in size. Uh oh.

Make sure your compiler is set with the /Wp64 switch on so that it will complain about code that will not work when you eventually compile it in 64-bit Windows (even if it compiles fine in 32-bit Windows), and you'll be well prepared. I also recommend compiling with the warning level set to /W4.

I should note that the type casting solution mentioned by Ness is not a perfect solution. When the original data type becomes 64-bits in size, you will lose information. Never type cast unless you have to. If you have to, ensure at least that you are not losing data before the type cast.

Here is an excellent page on the new data types to help prepare you for 64-bit Windows:
64-bit Windows Programming - The New Data Types