NULL macro vs. 0 as null pointer?

[Mabden]

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

Actually, I have always had plain text set. Something is IE is turning HTML
on when I respond to a(n) HTML posting. If anyone can verify / explain this
then perhaps I can avoid long meaningless conversations with post critics.

 

[Ioannis Vranos]

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.

NULL is a remain from C in which it was not always safe to assign 0
without a cast to a pointer. So in C it usually was:


#define NULL (void *)0



In C++ however, 0 by itself is guaranteed to be safe and the recommended
way to make a pointer have a null value. Also the above macro cannot
work in C++ due to the stricter type system (a void * is not converted
to any pointer type implicitly).


So (in case you wonder) my point is that you are right.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

 

[Ioannis Vranos]

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

Well for me

int *p=0;

or int *p;

// ...

p=0;


is always obvious since I know the meaning of these statements.

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)

As far as I know there is such a thing in C++/CLI draft and probably
will be adopted in a future revision of the standard, however that's
much high level for me but that's a matter of style, that is a
"religious" issue so anyone should act as he feels better without
prejudices, however myself always use 0 instead of '\0' anyway.


Example:

char whatever[10];

// ...
if(whatever==0)
// ...


instead of

if(whatever=='\0')
// ...



However both are legal and safe so '\0' is OK for me.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

 

[Julie]

Well for me

int *p=0;

or int *p;

// ...

p=0;

is always obvious since I know the meaning of these statements.

That is the WHOLE point -- what if you *don't* know the meaning of those
statements because of the loss of context?

For example, suppose that _one_ of the following statements is a bug (presume
int * p):


*p = 0;

//...

p = 0;

Please make your best guess as to where the problem is.

Now, consider the following:


*p = NULL;

//...

p = NULL;

Now, make your guess as to where the problem is.

 

[Daniel Graifer]

You guys are assuming that a NULL pointer is always an aritmetic zero.
There are hardware architectures where this is not true. Unisys
A-Series comes to mind. I've always thought the C++ convention of using
zero instead of a system defined NULL constant was a mistake.

dag

 

[Default User]

Actually, I have always had plain text set. Something is IE is turning HTML
on when I respond to a(n) HTML posting. If anyone can verify / explain this
then perhaps I can avoid long meaningless conversations with post critics.

Rather than try to figure out how to operate the worst newsreader
around, I'd suggest trying something else. Even this rather lame
Netscape reader is better and safer than Outlook Express (which is what
you are actually using).




Brian Rodenborn

 

[Andre Kostur]

You guys are assuming that a NULL pointer is always an aritmetic zero.
There are hardware architectures where this is not true. Unisys
A-Series comes to mind. I've always thought the C++ convention of using
zero instead of a system defined NULL constant was a mistake.

Actually we're assuming that an integer constant 0 is convertable to the
null pointer representation. Whatever the hardware-level representation of
a NULL pointer is, we (as a C++ program) don't care. That's the compiler's
job to translate the assignment of the integer constant 0 to a pointer into
whatever the hardware platform's representation is. (However, as
previously mentioned, I'm a fan of a specific nullptr keyword of some
sort....)

 

[Default User]

You guys are assuming that a NULL pointer is always an aritmetic zero.

It is, from a C or C++ perspective. If it isn't in a particular
platform, then it's up to the implementation to treat it as such anyway.

There are hardware architectures where this is not true. Unisys
A-Series comes to mind. I've always thought the C++ convention of using
zero instead of a system defined NULL constant was a mistake.

Like I said in previous posts, it was convention. I don't know the
details of why they did it versus creating a keyword that could be
implementation-defined.



Brian Rodenborn

 

[Ioannis Vranos]

That is the WHOLE point -- what if you *don't* know the meaning of those
statements because of the loss of context?

For example, suppose that _one_ of the following statements is a bug (presume
int * p):


*p = 0;

//...

p = 0;

Please make your best guess as to where the problem is.

Now, consider the following:


*p = NULL;

//...

p = NULL;

Now, make your guess as to where the problem is.

However this is a variable name issue. And *p above could be a **
pointer so essentially NULL doesn't help anywhere.

What about MyForm *pForm;

// ...


pForm=0;






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

 

[Michael D. Borghardt]

Try reading about nullptr

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1601.pdf