NULL vs. 0

[red floyd]

I searched the FAQ on this one, couldn't really find an answer.

Stylistically, is it better to use 0 or NULL?

I know that pre-Standard, 0 was recommended, because some compilers
implemented NULL improperly.

However, 18.1/4(footnote 180) indicates that 0 and 0L are valid NULLs,
while (void*)0 is explicitly invalid.

So, assuming a (reasonably) Standard compliant compiler, is there a
reason to continue to prefer 0 over NULL? NULL would seem to have the
advantage of indicating that we're checking a pointer.

Also, did nullptr make it into the C++0x draft?

 

[raddaq]

From "The C++ Language":

Zero (0) is an int. Because of standard conversions, 0 can be used as a
constant of any integral, floating-point, pointer, or pointer-to-member
type. The type of zero will be determined by context. Zero will
typically (but not always) be represented by a bit-pattern of all-zeros
of the appropriate size.
No object is allocated with the address of 0. Consequently, 0 acts as a
pointer literal, indicating that the pointer doesn't refer to an
object.
In C, it has been popular to define a macro NULL to represent a zero
pointer. Because of C++'s tighter type checking, the use of plain 0,
rather than any suggested NULL macro, leads to fewer problems.

 

[red floyd]

>
> Zero (0) is an int. Because of standard conversions, 0 can be used as a
> constant of any integral, floating-point, pointer, or pointer-to-member
> type. The type of zero will be determined by context. Zero will
> typically (but not always) be represented by a bit-pattern of all-zeros
> of the appropriate size.
> No object is allocated with the address of 0. Consequently, 0 acts as a
> pointer literal, indicating that the pointer doesn't refer to an
> object.
> In C, it has been popular to define a macro NULL to represent a zero
> pointer. Because of C++'s tighter type checking, the use of plain 0,
> rather than any suggested NULL macro, leads to fewer problems.

1. Please don't top post
(http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.4).
Rearranged to conform to c.l.c++ netiquette.

2. I have, and have read TC++PL3e. My point was that because the
Standard 18.1/4 specifies "The macro NULL is an implementation-defined
null pointer constant in this International Standard (4.10)." Footnote
180 to 18.1/4 specifically disallows (void*)0, is there any good modern
reason to use 0 instead of NULL anymore?

 

[Andrey Tarasevich]

...
So, assuming a (reasonably) Standard compliant compiler, is there a
reason to continue to prefer 0 over NULL? NULL would seem to have the
advantage of indicating that we're checking a pointer.
...

For that very reason it makes sense to prefer NULL over 0 in pointer context.
Otherwise, they are equivalent (in such contexts).

 

[Alf P. Steinbach]

* red floyd:

Footnote
180 to 18.1/4 specifically disallows (void*)0, is there any good modern
reason to use 0 instead of NULL anymore?

NULL generally indicates (to the human reader) a pointer value, in about
the same way that struct indicates (to the human reader) a POD.

When maintaining or adding to some existing code base, I think it would
be prudent to follow the conventions already established in that code.

Otherwise, I can't see much for or against any particular practice,
except that consistency is generally good, and except that I think it
would be ungood to mislead by using NULL for integer 0 or struct for a
very non-POD, non-aggregate class.

 

[red floyd]

For that very reason it makes sense to prefer NULL over 0 in pointer context.
Otherwise, they are equivalent (in such contexts).

Thanks Alf and Andrey. As I said, the 0 habit was from pre-Standard
days, based on old versions of TCPPPL (1st and 2nd editions!!!).

Just curious about prevailing style.

Thanks again!

 

[gottlobfrege]

2. I have, and have read TC++PL3e. My point was that because the
Standard 18.1/4 specifies "The macro NULL is an implementation-defined
null pointer constant in this International Standard (4.10)." Footnote
180 to 18.1/4 specifically disallows (void*)0, is there any good modern
reason to use 0 instead of NULL anymore?

You are asking why someone would *still* use 0 instead of NULL, as if
NULL was somehow better (ie maybe more descriptive).

I would rather ask why someone would *still* use NULL instead of 0?
NULL is a macro, 0 is what you are really saying - why hide that with
an unnecessary macro?

By the way, here is a 'gotcha' against using NULL, specifically with
regards to NULL being (incorrectly!) perceived as a null pointer:

void func(int x); // A
void func(char *ptr); // B

void foo()
{
func(NULL); // [1]
func(0); // [2]
}

At [1] which func is called, 'A' or 'B'? What about at [2]?

the 'gotcha' may seem obvious in this example, but when you are
debugging a bunch of code, I prefer to see what is really going on - 0,
not NULL.

Tony

P.S. macros are evil.

 

[Phlip]

I would rather ask why someone would *still* use NULL instead of 0?
NULL is a macro, 0 is what you are really saying - why hide that with
an unnecessary macro?

NULL's macro status is not a ding against it. NULL is a well-established
macro with no reason to collide or parse wrong, as new and non-Standard
macros might.

Use NULL to state your intent as clearly and prouncably as possible.

Using 0 just because "the Standard permits it" is sophomoric pedantry.

By the way, here is a 'gotcha' against using NULL, specifically with
regards to NULL being (incorrectly!) perceived as a null pointer:

void func(int x); // A
void func(char *ptr); // B

The guidelines against gratuitous overloads also apply here...

P.S. macros are evil.

So are 'if' statements, 'goto', 'cout', and anything else that can be
abused.

 

[Rolf Magnus]

NULL's macro status is not a ding against it. NULL is a well-established
macro with no reason to collide or parse wrong, as new and non-Standard
macros might.

Use NULL to state your intent as clearly and prouncably as possible.

That's self-contradictory. NULL is an integer, but one usually thinks of it
as a pointer, because it is only used in pointer context. So using NULL to
hide the fact that you have an integer is less clear than directly using 0.

Using 0 just because "the Standard permits it" is sophomoric pedantry.

I would say the same about using NULL just because the Standard inherited it
from C.

 

[Roy Smith]

NULL's macro status is not a ding against it. NULL is a well-established
macro with no reason to collide or parse wrong, as new and non-Standard
macros might.

Use NULL to state your intent as clearly and prouncably as possible.

Using 0 just because "the Standard permits it" is sophomoric pedantry.

Also, I can easily search for the string NULL in my source code. You don't
realize how important stuff like that is until you've got a million lines
of source code to slog trough trying to find constructs which might tickle
some new compiler bug that was just discovered.

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Also, I can easily search for the string NULL in my source code. You
don't realize how important stuff like that is until you've got a million
lines of source code to slog trough trying to find constructs which might
tickle some new compiler bug that was just discovered.

You can use something like:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }

That way you have easy searchability and type safety for a low price.

 

[gottlobfrege]

Thanks Alf and Andrey. As I said, the 0 habit was from pre-Standard
days, based on old versions of TCPPPL (1st and 2nd editions!!!).

Just curious about prevailing style.

The prevailing style is that it is a religious debate similar to where
you put your brackets, only the case of null, the standard is working
on resolving the debate.

 

[Phlip]

That's self-contradictory. NULL is an integer, but one usually thinks of
it
as a pointer, because it is only used in pointer context. So using NULL to
hide the fact that you have an integer is less clear than directly using
0.

http://groups.google.com/groups/search?q=kanze+null

If you think you have a stand here, you owe Kanze a post. ;-)

 

[Phlip]

You can use something like:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }

You have two typographical errors there. Allow me to fix them:

.... urn static_cast <T *> (NULL); }
.... tr) { return ptr == NULL; }

Aah, much more readable and pronouncable.

 

[Phlip]

The prevailing style is that it is a religious debate similar to where
you put your brackets, only the case of null, the standard is working
on resolving the debate.

Part of learning C++ is learning which style issues are really technical
issues. {} is style. NULL is technical.

 

[Noah Roberts]

* red floyd:

NULL generally indicates (to the human reader) a pointer value, in about
the same way that struct indicates (to the human reader) a POD.

A rather disagree that struct indicates POD. It is an artificial
indicator at best, one easily broken as the language makes no such
distinction. I don't think this is something that can be depended on
at all and therefore is no indicator that we have a POD vs. non-POD.

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

You have two typographical errors there. Allow me to fix them:

... urn static_cast <T *> (NULL); }
... tr) { return ptr == NULL; }

Aah, much more readable and pronouncable.

We can make another enhancement:

template <class T> bool isNull (T * ptr) { return isNull (ptr); }

Much more readable this way X-)

 

[Richard Herring]

You have two typographical errors there. Allow me to fix them:

... urn static_cast <T *> (NULL); }
... tr) { return ptr == NULL; }

And now to get the definition of NULL you have to #include some huge
header file in something which is itself going to be included all over
the place.

Aah, much more readable and pronouncable.

Who wants to do either?

 

[SuperKoko]

You are asking why someone would *still* use 0 instead of NULL, as if
NULL was somehow better (ie maybe more descriptive).

I would rather ask why someone would *still* use NULL instead of 0?
NULL is a macro, 0 is what you are really saying - why hide that with
an unnecessary macro?

There are several good reasons.
The best one : It is more human-friendly... You know the intent of the
programmer (assuming that the programmer uses NULL in pointer contexts
only).
But there are other reasons.
For instance, with Borland C++ 5.0 (for x86 CPU), in 16 bits real mode,
the definition of NULL depends on the memory model.
For memory models where pointers are 16 bits large (tiny, small,
medium), NULL is 0 (and int are 16 bits)
For memory models where pointers are 32 bits (compact, large, huge),
NULL is 0L (and long are 32 bits)
On this platform, the representation for the NULL pointer is
all-bits-zero, which is the same representation than the 0 integer
constant (both signed and unsigned).
Using NULL, can avoid bad behaviors in UB contexts.
For instance:
printf("%p", NULL); /* Undefined behavior : But works "as expected"
with Borland C++ */

P.S. macros are evil.

Even if the standard says that NULL is a macro, it can be a "harmless"
macro.
i.e., it can be implemented as:

/* dummy macro definition */
#define NULL NULL
const int NULL=0;


I would like to say that the fact that NULL is not type safe in C++
doesn't mean that it must not be used... Even if the compiler doesn't
make any difference between NULL and 0, programmers do.

I can think of very very old implementations of C, where "char*" and
"int" appeared to be almost semantically equivalent (because the
compiler did very very bad type checking, and dereferencing int was
"accepted" by the compiler).
But, it would be a very bad idea to use one type for the other.

 

[Sgt. York]

You have two typographical errors there. Allow me to fix them:

... urn static_cast <T *> (NULL); }
... tr) { return ptr == NULL; }

Aah, much more readable and pronouncable.

Chutzpah, man! You make a great point here. The hairs remain unsplit.