I think I understand the use of IntPtr, though I\'m really not sure.
I copied the IDisposable pattern from MSDN just to see what I could get from it, and w
IntPtr (this link actually says much of what I do) is a special form of integer that is the size of the pointer for the current bit-ness of the process -- the size is 4 bytes in 32bit x86, 8 bytes in 64bit x86, as this corresponds with the size a pointer.
While it can refer to a location in memory, it doesn't need to. As in the posted code, it could just refer to a handle or other opaque number. It is important because of the size changes in P/Invoked system calls (system calls use constant-sized integer while some depend on the architecture and pointers are always architecture dependent). An IntPtr
does not need to be disposed of itself, but the opaque number contained in it may refer to a resource that does need releasing; this is all part of the API contract with where the value was obtained.
See new IntPtr(long)
and IntPtr.ToInt32/ToInt64
for conversions to/from a standard numeric type (on a 64-bit environment it is possible that ToInt32
will throw an overflow exception).
And no, while obtaining a value for the IntPtr
(e.g. calling P/Invoked function) may require the appropriate security permissions, there is no unsafe code required (see the link or what unsafe
allows) -- but arguably anything that talks to native code is "unsafe" as it can cause a nice process crash ;-)
Happy coding.