In the early days of C++ when it was bolted on top of C, you could not use NULL as it was defined as (void*)0
. You could not assign NULL to any pointer other than void*
, which made it kind of useless. Back in those days, it was accepted that you used 0
(zero) for null pointers.
To this day, I have continued to use zero as a null pointer but those around me insist on using NULL
. I personally do not see any benefit to giving a name (NULL
) to an existing value - and since I also like to test pointers as truth values:
if (p && !q)
do_something();
then using zero makes more sense (as in if you use NULL
, you cannot logically use p && !q
- you need to explicitly compare against NULL
, unless you assume NULL
is zero, in which case why use NULL
).
Is there any objective reason to prefer zero over NULL (or vice versa), or is all just personal preference?
Edit: I should add (and meant to originally say) that with RAII and exceptions, I rarely use zero/NULL pointers, but sometimes you do need them still.
I'm with Stroustrup on this one :-) Since NULL is not part of the language, I prefer to use 0.
I usually use 0. I don't like macros, and there's no guarantee that some third party header you're using doesn't redefine NULL to be something odd.
You could use a nullptr object as proposed by Scott Meyers and others until C++ gets a nullptr keyword:
Google "nullptr" for more info.
Well I argue for not using 0 or NULL pointers at all whenever possible.
Using them will sooner or later lead to segmentation faults in your code. In my experience this, and pointers in gereral is one of the biggest source of bugs in C++
also, it leads to "if-not-null" statements all over your code. Much nicer if you can rely on always a valid state.
There is almost always a better alternative.
The moral of the story. You should use NULL when you're dealing with pointers.
1) It declares your intent (don't make me search through all your code trying to figure out if a variable is a pointer or some numeric type).
2) In certain API calls that expect variable arguments, they'll use a NULL-pointer to indicate the end of the argument list. In this case, using a '0' instead of NULL can cause problems. On a 64-bit platform, the va_arg call wants a 64-bit pointer, yet you'll be passing only a 32-bit integer. Seems to me like you're relying on the other 32-bits to be zeroed out for you? I've seen certain compilers (e.g. Intel's icpc) that aren't so gracious -- and this has resulted in runtime errors.
I prefer to use NULL as it makes clear that your intent is the value represents a pointer not an arithmetic value. The fact that it's a macro is unfortunate, but since it's so widely ingrained there's little danger (unless someone does something really boneheaded). I do wish it were a keyword from the beginning, but what can you do?
That said, I have no problem with using pointers as truth values in themselves. Just as with NULL, it's an ingrained idiom.
C++09 will add the the nullptr construct which I think is long overdue.
Setting a pointer to 0 is just not that clear. Especially if you come a language other than C++. This includes C as well as Javascript.
I recently delt with some code like so:
virtual void DrawTo(BITMAP *buffer) =0;
for pure virtual function for the first time. I thought it to be some magic jiberjash for a week. When I realized it was just basically setting the function pointer to a
null
(as virtual functions are just function pointers in most cases for C++) I kicked myself.virtual void DrawTo(BITMAP *buffer) =null;
would have been less confusing than that basterdation without proper spacing to my new eyes. Actually, I am wondering why C++ doesn't employ lowercase
null
much like it employes lowercase false and true now.