Can using 0L to initialize a pointer in C++ cause problems?

Question

In this question an initializer is used to set a pointer to null. Instead of using value of 0 value of 0L is used. I've read that one should use exactly 0 for null pointers because exact null pointer representation is implementation-specific.

Can using 0L to set a pointer to null cause problems while porting?

Solution 1

From the standard (4.10.1):

A null pointer constant is an integral constant expression (5.19) rvalue of integer type that evaluates to zero

so I guess 0L is ok.

Solution 2

I think 0L is fine, except for the fact that it would imply that you believe the pointer type your assigning to is the same size as a long, and so is a bit confusing.

I think using NULL is much more clear.

Solution 3

In C++0x there is a new null pointer constant called nullptr of type nullptr_t. It can be implicitly converted to any pointer type.

Until then I would recommend using NULL, however 0 and 0L will both work on every implementation I've ever heard of.

Solution 4

I can't give you an exact answer, but regardless of what the exact answer to your question is, just the idea itself of initializing a pointer with 0L is wrong, because it suggests that a pointer is the same size as a long, which is not necessarily true, ofcourse.

Whether the compiler accepts it or not, and whether it's safe or not, I wouldn't do it because it suggests an invalid idea.

Solution 5

I would disagree with those who recommend using NULL, though any of the three stated options would indeed work. In idiomatic C++, the standard choice is 0 (perhaps because that's Stroustrup's preference: http://www2.research.att.com/~bs/bs_faq2.html#null).

0L will be implicitly cast to the appropriate pointer type in the same way as 0 would be; it just looks a bit strange and doesn't really make a great deal of sense for the reason Jesper gave..

View more solutions

Comments

[Admin]

Does that mean that initialising it with 0 suggests it is the same size as an int? I don't think so.

[wheaties]

+1 because NULL is more clear to those maintaining the software. Trust me, I've seen deadbeef and 0 used in the same project.

[dicroce]

No, because 0 does not imply an int.

[KernelJ]

0xDEADBEEF is especially bad. 0 is the only value you can always set a pointer to be (a null pointer), and it doesn't matter what size the pointer is.

[David Rodríguez - dribeas]

What problems do you refer to? AFAIK, the compiler will perform the required type conversions.

[KernelJ]

The value 0 can be cast to any size of integer from any other.

[Jesper]

@Neil: Even if it does, it's less bad than explicitly saying 0L, because the L strongly suggests that it's supposed to be understood as a long. Just 0 doesn't necessarily by itself imply that it's an int.

[David Rodríguez - dribeas]

I do prefer 0 also, but that is just a matter of taste, I guess.

[KernelJ]

I think the fact that you're explicitly saying the value is a long is the problem here.

[McPherrinM]

0 is defined to work in the C++ standard. NULL is just a macro carried over from C.

[Brian R. Bondy]

defined as 0, still I have a preference to NULL as I personally think it looks cleaner.

[David Thornley]

NULL is legal and idiomatic. 0 is legal and idiomatic. 0L is legal but not idiomatic. 0xDEADBEEF is either unspecified or undefined, and certainly isn't a null pointer constant. I'm looking forward to nullptr myself.

[josesuero]

You are not assigning "a long integer", but "the null pointer constant". And that is guaranteed to work, regardless of the bit width of integers or pointers.

[KernelJ]

Seven characters for something which is basically a 0 is asking a bit much I think. I can't think why so much verbosity is required, when we have NULL already. Maybe it has some special uses in the new standard but I haven't really looked at it.

[Jesper]

@KernelJ: Yes, that's exactly what I mean.

[MSalters]

Overload resolution. Given f(int) and f(int*), f(NULL) calls f(int) but f(nullptr) calls f(int*).

[MSalters]

I personally prefer if (!some_variable) { }

[codencandy]

All of you are right, my thinking was that assignment of 64 bit integers to a 32 bit pointer would be invalid. but as you mentioned the compiler will convert the constant to the required type.

[KernelJ]

Yeah, that's great but... Anyone who overloads functions like that needs to be shot.

[Bill]

Note: Stroustrup recommends using nullptr when that's available, so he's not recommending 0 so much as recommending against using a macro.

[dan04]

@KernelJ: print(int) and print(char*) is a perfectly reasonable overload.