Last post Oct 18, 2010 08:10 AM by SGWellens
Oct 18, 2010 06:23 AM|stevebravo|LINK
The idea with System.IntPtr is to represent an integer whose width in bits correspond to the size of a pointer in the hardware and operating system that the CLR is running in, it's platform specific in other words. It supports 32-bit and 64-bit architectures
This is a legacy from old-style C API's where pointers and ints were frequently treated as interchangeable. The Win32 API has many such parameters, where the width varies with the underlying architecture - thus the mess with porting of code from 32-bit
to 64-bit (we already did this once when going from 16-bit to 32-bit, funny how we never learn...).
In practice, as is mentioned in other responses, it can be used to hold unmanaged resource handles and pointers etc that stem from the underlying Win32 functions. It can also be used to hold integers of the natural size for current platform. You can
also use IntPtr.Size to dtermine the size of a pointer on the current platform.
SO when you explain this to a child ;) this would be used to let program's flow at the same speed at diffrent kinds of operating systems?
Oct 18, 2010 08:10 AM|SGWellens|LINK
this would be used to let program's flow at the same speed at diffrent kinds of operating systems?
No. It has nothing to do with speed.
Using a "flexible" data size allowed programs to be ported easily to different machines (8-bit, 16-bit, 32-bit, etc.). The pointers would always be the correct size...the size of the CPU's hardware registers.