NULL macro vs. 0 as null pointer?

[jeffc]

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.

That's fine, but the problem is there's no alternative to the convention
(other than some other even more arbitrary number). Just saying
#define NULL 0
doesn't change anything in the slightest. It's still 0, and you still can't
access memory address 0 on a system where it's valid. Now if you had an
abstract pointer type, analogous to the new bool type, then it would be
different.

 

[Default User]

Uuuuhhh... it's not. Ever. In C.

Wrong. The physical address 0 could be. The logical address 0 can't be.
It's up to the implementation to make sure that is the case.

Again, a convention.



Brian Rodenborn

 

[Default User]

That's fine, but the problem is there's no alternative to the convention
(other than some other even more arbitrary number). Just saying
#define NULL 0
doesn't change anything in the slightest. It's still 0, and you still can't
access memory address 0 on a system where it's valid. Now if you had an
abstract pointer type, analogous to the new bool type, then it would be
different.

I disagree. It helps the maintainer realize that the integer 0 is going
to be assigned to a pointer. That's using 0 in a different way and with
a different meaning that an integer assignment.

As I said, an implementation may have to do some magic with that 0 to
make sure it's an invalid pointer in all uses. It doesn't hurt to have a
special macro to make it clear to the designer and maintainer.

But it's not a big deal either.



Brian Rodenborn

 

[Mabden]

Mabden wrote:


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.

Uuuuhhh... it's not. Ever. In C.
Hi. Here's an excerpt from a useful link provided by a poster in this thread:

http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1488.pdf
[snip]

The C++ definition of null pointer does not include (void *)0, whereas the C definition does.

I hope that helps--without flames .

Yeah, I've heard that from someone else. I didn't realize that.

But the OP mentioned memory location Zero which is not possible in C. I assume it is also impossible in C++.

 

[Mabden]

Wrong. The physical address 0 could be. The logical address 0 can't be.
It's up to the implementation to make sure that is the case.

Again, a convention.

Where the hell is Dan Pop when I _need_ him?!

 

[Mabden]

Mabden wrote:

Any thoughts?

Um, "don't top-post".

Rough crowd. Where's Colin Quinn when you need him.

Tell me about it. BTW, also don't post HTML. ;-)

 

[Mabden]

Uh... we really should get a new shorthand for Bjarne... somehow Bjarne's
name wasn't the first thing that came to mind when I saw "BS" (hint: the B
referred to a male cow.... )

Hehe yeah, I only saw "BS" used lately, but I like for a couple of reasons:

o He has a web site to show how to pronounce His name:
http://www.research.att.com/~bs/bs_faq.html#pronounce

o He called C "Old C" and his work "C" until told to stop - much hubris
there. BS to BS!

 

[Default User]

Where the hell is Dan Pop when I _need_ him?!

He'd probably be telling to quit using HTML in most of your posts.




Brian Rodenborn

 

[Mabden]

He'd probably be telling to quit using HTML in most of your posts.

With a little more abuse, I'm sure. Yeah I tried copying it to notepad
first, but when I reply to HTML, I get HTML. Just another fucked up OE bug I
guess.

I don't know if two can be considered "most", but I guess you know best.

 

[Ioannis Vranos]

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?

From TC++PL 3, on page 88:


"5.1.1 Zero

Zero (0) is an int. Because of standard conversions (§C.6.2.3), 0 can be
used as a constant of any integral (§4.1.1), floating-point, pointer, or
pointer-to-member type. The type of zero will be determined by context.
Zero will typically (but not necessarily) be represented by the bit
pattern all-zeros of the appropriate size.

No object is allocated with the address 0. Consequently, 0 acts as a
pointer literal, indicating that a pointer doesn’t refer to an object.

In C, it has been popular to define a macro NULL to represent the zero
pointer. Because of C++’s tighter type checking, the use of plain 0,
rather than any suggested NULL macro, leads to fewer problems. If you
feel you must define NULL, use

const int NULL = 0;

The const qualifier (§5.4) prevents accidental redefinition of NULL and
ensures that NULL can be used where a constant is required."






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

 

[jeffc]

Take a chill boss.

Victor is pretty uptight - he'll have his monthly bowel movement soon, and
will be back to helping people forthwith.

 

[jeffc]

So according to the C++ standard,
the constant 0, when used as a pointer rvalue, is really an abstraction
for null pointer.

So why put an abstraction on top of an abstraction? What's the point? It's
just one of those things that you have to know when using C++ - 0 means
invalid pointer. Using NULL doesn't free you from understanding this
concept, and you won't be redefining NULL at a later date because something
in your system changes (as would be the case, for example, with a magic
number like MAX_ARRAY_SIZE or something.) So in my mind there are zero
advantages to using a macro NULL. If you don't understand that 0 is a null
pointer, and you're using NULL to shield yourself from having to get that
knowledge, you're going to run into trouble. If you do understand that 0 is
a null pointer, then there isn't any reason to add NULL as an extra layer of
veneer to your program. If NULL were a keyword, like true and false are for
bool, then that would be a different matter. Then the implementation of 0
for null pointer would be irrelevant. But until we get such a keyword, 0 is
the most obvious and direct symbol to use. Obviousness and directness are
good, unless you have good reason to obfuscate.

 

[Andre Kostur]

So why put an abstraction on top of an abstraction? What's the point?
It's just one of those things that you have to know when using C++ -
0 means invalid pointer. Using NULL doesn't free you from
understanding this concept, and you won't be redefining NULL at a
later date because something in your system changes (as would be the
case, for example, with a magic number like MAX_ARRAY_SIZE or
something.) So in my mind there are zero advantages to using a macro
NULL. If you don't understand that 0 is a null pointer, and you're
using NULL to shield yourself from having to get that knowledge,
you're going to run into trouble. If you do understand that 0 is a
null pointer, then there isn't any reason to add NULL as an extra
layer of veneer to your program. If NULL were a keyword, like true
and false are for bool, then that would be a different matter. Then
the implementation of 0 for null pointer would be irrelevant. But
until we get such a keyword, 0 is the most obvious and direct symbol
to use. Obviousness and directness are good, unless you have good
reason to obfuscate.

Problem is that "obviousness" is in the eye of the beholder. To me, NULL
makes it blazingly obvious that one is attempting to cause a pointer to
be set to the null pointer representation, not that you may to attempting
to modify an int, but whups! That's a pointer....

As soon as the "nullptr" keyword is added to the language (which is a
rumour I hear, and as soon as I get compilers that support it), you can
be sure I will be switching to that syntax as soon as possible. I fully
understand that 0 means the same thing (or more accurately, NULL means
the same thing as 0, in the compilers I use)

Basically I like NULL since the code then "speaks" to me. Same reason
why I hate to implicitly compare to 0 in boolean expressions. Yes, I
fully understand that 0 is false, and everything else is true. But
saying:

if (someVariable)

Doesn't "speak" to me, unless someVariable actually is a bool variable.
Anything else, and it's:

if (someVariable != 0)

or:

if (someVariable != NULL)

if it's a pointer.

My preference... (and $0.02 CDN)

 

[Julie]

So why put an abstraction on top of an abstraction? What's the point? It's
just one of those things that you have to know when using C++ - 0 means
invalid pointer. Using NULL doesn't free you from understanding this
concept, and you won't be redefining NULL at a later date because something
in your system changes (as would be the case, for example, with a magic
number like MAX_ARRAY_SIZE or something.) So in my mind there are zero
advantages to using a macro NULL. If you don't understand that 0 is a null
pointer, and you're using NULL to shield yourself from having to get that
knowledge, you're going to run into trouble. If you do understand that 0 is
a null pointer, then there isn't any reason to add NULL as an extra layer of
veneer to your program. If NULL were a keyword, like true and false are for
bool, then that would be a different matter. Then the implementation of 0
for null pointer would be irrelevant. But until we get such a keyword, 0 is
the most obvious and direct symbol to use. Obviousness and directness are
good, unless you have good reason to obfuscate.

As I've tried to explain in previous posts, it can come down to an issue of
ambiguity in code.

For example, suppose that you have a bug or are otherwise examining
(self-documenting, uncommented) code that is using an int * p, and you see:

p = 0;

So, is the intent to assign p to 'null' (in this case, a bug), or to assign 0
to what p points to? For me, if used consistently, using NULL can
disambiguate:

p = NULL;

Now, the intent is clear. Further:

*p = NULL;

Highly suspicious, probable bug or otherwise incorrect code.

You just can't get that by using 0 alone because without explicit context, 0
can have multiple meanings. NULL is much more context insensitive.

In my opinion, BS or the stds committee *should* have included a specific
'null' pointer constant in the beginning to avoid the ambiguity.

So, in response to your statement, yes, directness is good, but using 0 can be
far from obvious.

 

[Default User]

With a little more abuse, I'm sure. Yeah I tried copying it to notepad
first, but when I reply to HTML, I get HTML. Just another fucked up OE bug I
guess.

I don't know if two can be considered "most", but I guess you know best.

Let's say that two of the three I read from you yesterday were. For that
extremely limited sample size, "most" was correct




Brian Rodenborn

 

[George Privalov]

So why put an abstraction on top of an abstraction? What's the point? It's
just one of those things that you have to know when using C++ - 0 means
invalid pointer. Using NULL doesn't free you from understanding this

C++ is using 0 in pointer context as a keyword. No other number
except 0 is accepted. So there is no point to add any 'nullptr'
keyword. Although I stil use NULL since it's easier to search for it
in files.

G.P.

 

[Mabden]

Let's say that two of the three I read from you yesterday were. For that
extremely limited sample size, "most" was correct

I didn't notice the first one went HTML until it posted, and when I did, I
tried running the next one through notepad to clean it up. That failed to
work. Oh well.

It's always nice to hear about ones flaws in public, and I look forward to
hearing from you again.

BTW, I don't believe HTML is outlawed in this newsgroup, so I could suggest
you mind your own business, but that might seem unkind and one doesn't wish
to offend.

 

[Karl Heinz Buchegger]

C++ is using 0 in pointer context as a keyword.

Ahm. No
Any const expression with a value of 0 is acceptable.

char* p = 2 - 2;
is valid.

 

[George Privalov]

Ahm. No
Any const expression with a value of 0 is acceptable.

char* p = 2 - 2;
is valid.

OK, it's not treated literally as a keyword but very close, if you try
this it will not be valid:

extern int n;
char* p = n-n;

Funny isnt' it? I can understand sense of it if n would be volatile.
And we can go on into phyloshical discussion on how come 2-2 is not
the same as n-n, but answer is purely technical. 2-2 is evaluated at
early stages of compile while n-n is at optimization stages. Thus,
2-2 is almost treated as a keyword. Still the discussion should be on
what is more practical. I would argue the literal keyword or NULL is
more practical since lets you grep through pointer assignments.

G.P.

 

[Default User]

I didn't notice the first one went HTML until it posted, and when I did, I
tried running the next one through notepad to clean it up. That failed to
work. Oh well.

It's more a setting of your newsreader that's important.

It's always nice to hear about ones flaws in public, and I look forward to
hearing from you again.

That's one of the essential features of newsgroups, what one says is
there for the world to see. And comment upon.

BTW, I don't believe HTML is outlawed in this newsgroup, so I could suggest
you mind your own business, but that might seem unkind and one doesn't wish
to offend.

Ah, but you could have checked the FAQ, and know that that was untrue:

"Do not post HTML or "rich text." Like it or not, comp.lang.c++ is a
plain-text newsgroup."

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.4


See, aren't you happy you weren't unkind? That saved you trouble of
apologizing later.




Brian Rodenborn