NULL macro vs. 0 as null pointer?

K

Ken

Hi all. When referring to a null pointer constant in C++, is there
any reason to prefer using 0 over a macro called NULL that is defined
to be 0?

Thanks!

Ken
 
A

Andre Kostur

(e-mail address removed) (Ken) wrote in @posting.google.com:
Hi all. When referring to a null pointer constant in C++, is there
any reason to prefer using 0 over a macro called NULL that is defined
to be 0?

Thanks!

Well... somewhat thorny issue (let the religious war begin!). According
to the Standard, 0 is the thing to use. I prefer to use NULL. One of
the original drawbacks was that NULL wasn't #defined to be a simple 0.
It would be #defined to other things like "(void*)0".

I prefer to use NULL to keep the reminder that I'm dealing with a
pointer, and not a simple integral type. Then again, I also despise
writing any implicit boolean checks, except against a bool type.
Example, I hate to write:

char * cp;

if (cp)
{
// do stuff
}


I will always explicitly check against NULL:

if (cp != NULL)


Same for integers.
 
S

Siemel Naran

Ken said:
Hi all. When referring to a null pointer constant in C++, is there
any reason to prefer using 0 over a macro called NULL that is defined
to be 0?

There's no reason. NULL is more commonplace whereas 0 looks like an
integer, but people use both ways all the time.

I think in C NULL is defined as 0. In C++ it is (void*)0.
 
J

jeffc

Ken said:
Hi all. When referring to a null pointer constant in C++, is there
any reason to prefer using 0 over a macro called NULL that is defined
to be 0?

Yes. The value is 0. Why do we need an abstraction of that? Sometimes
abstractions help, but in this case I don't see what's more clear than 0.
Let's say you did this
#define ONE 1

Then in your code you did this

int x = ONE;

Does this help you in any way? What would happen if the value of ONE
changed someday? Normally you'd only want such a macro if the value of some
"magic number" actually were going to change in the future, or in some other
environment or platform, or if the name was somehow much more meaningful
than the number. I think it would be a really really bad idea to change the
value of ONE, ever, and it certainly isn't any more readable than "1".
 
J

Julie

Ken said:
Hi all. When referring to a null pointer constant in C++, is there
any reason to prefer using 0 over a macro called NULL that is defined
to be 0?

There is no right answer, and from an 'enforcement' standpoint, you will only
cause problems.

If you are simply asking for yourself, you will need to decide what suits you
best.

The general thoughts are:

- NULL can make it more clear in the code that you are expecting and dealing
with pointers, but NULL is not part of the language proper, but part of the
library (meaning that you must include a library before it is defined).

- 0 requires no support library (i.e. it is part of the language proper), but
it can lead some loss of code clarity when dealing w/ pointers (specifically
integer pointers, is the intent to compare the pointer or the destination of
the pointer?)
 
R

Rolf Magnus

Ken said:
Hi all. When referring to a null pointer constant in C++, is there
any reason to prefer using 0 over a macro called NULL that is defined
to be 0?

The usage of NULL can produce unexpected results if you are not fully
aware that it is the same as 0.
The following program for instance will print "int":

#include <iostream>
#include <cstdlib>

void x(int i)
{
std::cout << "int\n";
}

void x(char* c)
{
std::cout << "char*\n";
}

int main()
{
x(NULL);
}

When you use NULL, this might be a surprise (thinking of NULL as a
pointer), whereas with 0, it's clear that the int version is used.
 
J

JKop

Ken posted:
Hi all. When referring to a null pointer constant in C++, is there
any reason to prefer using 0 over a macro called NULL that is defined
to be 0?

Thanks!

Ken


I myself prefer

#define WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK 0


int main()
{
int* p_j = WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK;
}


-JKop
 
J

Julie

JKop said:
Ken posted:


I myself prefer

#define WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK 0

int main()
{
int* p_j = WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK;
}

-JKop

For US English:

#define WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_BARF \
WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK
 
D

Default User

jeffc said:
Yes. The value is 0. Why do we need an abstraction of that? Sometimes
abstractions help, but in this case I don't see what's more clear than 0.
Let's say you did this
#define ONE 1

Then in your code you did this

int x = ONE;


That's a poor example. A better one would be one common in the old days
of C before boolean types:

#define TRUE 1

Here you are creating a macro because there is some conceptual
difference in the way it's used.

Similarly, the reason for defining a NULL macro is because there's a
conceptual difference between the integer 0 and a null pointer. There's
no particular reason why 0 has to be the null pointer, it's merely
convention.

There is a preference in C++ to use 0 vs. NULL.



Brian Rodenborn
 
V

Victor Bazarov

Julie said:
For US English:

#define WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_BARF \
WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK

This produces undefined behaviour because it has double underscores
in the identifier thus making it reserved.

V
 
J

JKop

Victor Bazarov posted:
This produces undefined behaviour because it has double underscores
in the identifier thus making it reserved.

V


It doesn't contain double underscores, it contains single
underscores and quadruple underscore. A quadruple
underscore is no more two double underscores than a tandum
bike is two bikes.

-JKop
 
J

jeffc

Default User said:
That's a poor example. A better one would be one common in the old days
of C before boolean types:

#define TRUE 1

Here you are creating a macro because there is some conceptual
difference in the way it's used.

That's a fine example.
Similarly, the reason for defining a NULL macro is because there's a
conceptual difference between the integer 0 and a null pointer.

I disagree. A pointer holds a numeric value., and 0 means something. It
would take a different sort of object to represent something more
sophisticated (like bool does.) In lieu of that, I think NULL is an
unnecessary abstraction. What mean is precisely 0. Contrast this with the
TRUE example above - what we mean is non-FALSE, or non-zero. There's no
numeric equivalent to that. It's a concept that can't be expressed well
with a specific numeric value.
 
J

jeffc

JKop said:
It doesn't contain double underscores, it contains single
underscores and quadruple underscore. A quadruple
underscore is no more two double underscores than a tandum
bike is two bikes.

It is if the preprocessor ignores everything after the first 2 underscores
wrt to naming rules.
 
A

Andre Kostur

jeffc said:
I disagree. A pointer holds a numeric value., and 0 means something.
It would take a different sort of object to represent something more
sophisticated (like bool does.) In lieu of that, I think NULL is an
unnecessary abstraction. What mean is precisely 0. Contrast this
with the TRUE example above - what we mean is non-FALSE, or non-zero.
There's no numeric equivalent to that. It's a concept that can't be
expressed well with a specific numeric value.

OK, this may simply be an argumentative answer, but if a pointer only holds
"a numeric value", then why have pointer types at all? Why not just use
unsigned long (or whatever may make sense for the target platform)? To me,
a pointer and a numeric value are two separate beasts. Granted, you can do
some aritmetic operations on a pointer value... but I still thing of them
as different things.
 
D

Default User

jeffc said:
I disagree. A pointer holds a numeric value., and 0 means something.

Yes, but it doesn't mean "invalid" necessarily. A null pointer isn't
really "true" or "false", it's a memory location. It just so happens
that in C they decided to make the value 0 mean invalid. They could have
picked something else, but 0 is a nice easy number.
It
would take a different sort of object to represent something more
sophisticated (like bool does.) In lieu of that, I think NULL is an
unnecessary abstraction. What mean is precisely 0.

What about a system where 0 is a perfectly valid memory location? Then 0
isn't precisely anything. It's a convention, and a convenient one.



Brian Rodenborn
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top