NULL vs. 0

>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 wrote:

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?

ra****@gmail.co m wrote:

red floyd wrote:

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?

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.

1. Please don't top post
(http://www.parashift.com/c++-faq-lit....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?

red floyd wrote:

...
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).

--
Best regards,
Andrey Tarasevich

* 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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Andrey Tarasevich wrote:

red floyd wrote:

...
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).

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!

red floyd wrote:

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.

gottlobfrege wrote:

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.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

Phlip wrote:

gottlobfrege wrote:

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.

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.

In article <R4************ ******@newssvr1 4.news.prodigy. com>,
"Phlip" <ph******@yahoo .com> wrote:

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.