new IntPtr(0) vs. IntPtr.Zero

Question

Is there any difference between the two statements:

IntPtr myPtr = new IntPtr(0);
IntPtr myPtr2 = IntPtr.Zero;

I have seen many samples that use PInvoke that prefer the first syntax if the myPtr argument is sent by ref to the called function. If I'll replace all new IntPtr(0) with IntPtr.Zero in my application, will it cause any damage?

Solution 1

IntPtr is a value type, so unlike String.Empty there's relatively little benefit in having the static property IntPtr.Zero

As soon as you pass IntPtr.Zero anywhere you'll get a copy, so for variable initialisation it makes no difference:

IntPtr myPtr = new IntPtr(0);
IntPtr myPtr2 = IntPtr.Zero;

//using myPtr or myPtr2 makes no difference
//you can pass myPtr2 by ref, it's now a copy

There is one exception, and that's comparison:

if( myPtr != new IntPtr(0) ) {
    //new pointer initialised to check
}

if( myPtr != IntPtr.Zero ) {
    //no new pointer needed
}

As a couple of posters have already said.

Solution 2

They are functionally equivalent, so it should cause no problems.

IntPtr.Zero represents the default state of the structure (it is declared but no constructor is used), so the default value of the intptr (void*) would be null. However, as (void*)null and (void*)0 are equivalent, IntPtr.Zero == new IntPtr(0)

Edit: While they are equivalent, I do recommend using IntPtr.Zero for comparisons since it simply is easier to read.

Solution 3

The use of IntPtr.Zero will allow you to avoid a new instance of IntPtr.

from msdn:

Use this field to efficiently determine whether an instance of IntPtr has been set to a value other than zero

Solution 4

What happens if you pass IntPtr.Zero by ref, and the recipient tries to modify the reference? From that moment forth, would IntPtr.Zero != new IntPtr(0), or would the recipient receive some kind of exception upon trying to make the change?

I'm not sure about this, but it seems like a reasonable explanation.

View more solutions

Comments

[user]

IntPtr.Zero is more readable. I think stick to it will be better

[Tobias]

That's what I think too... :) So why there are about a million samples on the web that use the new IntPtr(0)? Isn't it better to use the static variable version?

[Meydjer Luzzoli]

-1: The first paragraph is not correct. new IntPtr(0) does not create an uninitialized IntPtr; it creates one that is explicitly initialized to zero. As does IntPtr.Zero. The two are absolutely semantically identical.

[Dovi]

The point is that IntPtr.Zero can potentially be changed to be equal to something other than zero without breaking any third-party code.

[Tobias]

That's what I was afraid of... But I think that it doesn't happen. Because I'm not really sending IntPtr.Zero by ref. I'm probably sending a boxing of the myPtr. But I'm not really sure about it either... Hence my question... :)

[Meydjer Luzzoli]

No, it can't. It is an IntPtr with a value of zero, as the name indicates. From MSDN: "A read-only field that represents a pointer or handle that has been initialized to zero." (msdn.microsoft.com/en-us/library/system.intptr.zero.aspx)

[binarydreams]

If you assign IntPtr.Zero to a variable before passing it to your other method, you are not passing IntPtr.Zero but a local copy (it's a struct).

[Jakob Dam Jensen]

true, but in that does not apply to either of the cases the OP mentions.

[Lee Louviere]

He means in a new .Net platform, IntPtr.Zero could equal 5, and no code would be broken. However, you're wrong in that, since it's a value type, it would break code if they changed it. As the people doing checks with it would have the compiler hard code the value 0 in.

[Nyerguds]

A pointer is literally an address in memory. You can't use fixed values as defaults for that; these addresses might actually be used. Whereas 0 points at the very start of the memory addressing; something that should never be accessed by upper level stuff since it's probably the core of the boot mechanism.