not null

[Julie]

Rolf Magnus posted:


LMAO!!!

This conversation is so stupid!!!

if (number != 0) //This is pidgeon C++

if (number) //This is proper!

Similarly:

void Grent(unsigned int* pK)
{
if (!pK) throw "ahhh!!!!!";
}

Who said anything about proper? For such a stupid thread, you are now below
it...

if (ptr != 0) //correct, intent not immediately clear

if (*ptr != 0) // intent clear

if (ptr != NULL) // correct, intent is clear

if (ptr) // correct, intent not immediately clear

if (*ptr) // intent clear

For most, this will come down to an issue of style, to others (including me),
an issue of self-documenting code. There is no right answer the way the
language is currently defined and implemented.

 

[Julie]

So is your point that NULL is not part of C++???

[-]
It's neither part of the C nor of the C++ language. If you
want it you ...

C++ : #include <cstddef> [see ISO-IEC-14882 : "18.1 Types"]
C : #include <stddef.h>

... either need to include some header file or define your own version.

Unfortunately 0 instead of NULL isn't the final solution for all
cases either, as if you've something like this ...

class C {
public :
void f( int );
void f( C* );
};

.. you'd need something like this ...

class C {
public :
void f( int );
void f( C* );

static C* const NULL_;
};

C* const C::NULL_ = 0;

.. in order to be able to write ...

some_c.f( C::NULL_ );

.. instead of the more verbose version ...

some_c.f( static_cast<C*>(0) );

.. if the 2nd f() function is to be called.

Ta',
Juergen

Which is why I feel that it would be beneficial to add NULL formally to the
language as an intrinsic pointer type. In my opinion, it would allow you to
differentiate between int and pointer arguments, as well as facilitate
self-documenting code. Probably ain't going to happen though, and this isn't
the forum to discuss such.

 

[Jorge Rivera]

For most, this will come down to an issue of style, to others (including me),

an issue of self-documenting code. There is no right answer the way the
language is currently defined and implemented.

I understand your concern. However, someone who doesn't understand that
0 is a null value for a pointer should not be reading the code, but
rather a basic introductory course in C or C++.

JLR

 

[Julie]

I understand your concern. However, someone who doesn't understand that
0 is a null value for a pointer should not be reading the code, but
rather a basic introductory course in C or C++.

JLR

I don't disagree w/ that at all -- what I'm talking about is this case which
may be the source of a bug, or not, depending on context:

int * pint = new int;
*pint = 0;

// lots of code that fiddles w/ pint, including
// conditionally deleting pint and setting it to 'null'

if (pint != 0) // Bug? what is intended here, it could be any of the
following:

if (pint != 0) // check for 'null' pointer?
if (*pint != 0) // does pint point to a zero value?


I have had to spend a considerable amount of time debugging other's code, and
cases such as this are not terribly uncommon. I must then try to determine
what the author's original intent is by studying the context of the code. A
lot of this could be avoided if there were an intrinsic NULL pointer type, and
that were used in pointer-null comparisons. Alas, that didn't happen at the
outset of C/C++, and we/I am left w/ code in which the intent isn't immediately
clear... So, to hopefully counter that, I only use NULL in pointer
comparisons, and have found that my code is more clear, and hopefully more
maintainable for those that follow.

 

[Jack Klein]

The standard C headers are a base part of the C++ language, just like
the C++ headers are.


NULL is also correct (if you #include <cstdlib> oder <stdlib.h>), but 0
is to be preferred.

The term "preferred" does not appear and is not defined by the
standard. The macro NULL is not deprecated, so you are offering an
opinion on style, not a matter of the language.

 

[Jack Klein]

It is part of some of the header files.


If this compiles your C++ compiler is broken:


int main() {
int i;
int *p = &i;
if (p == NULL)
return 1;
return 0;
}


Having to include some header file, especially one of the C library
ones, just to get a simple program that does a trivial comparison to
compile is not good.

Quite interesting. Of course, none of:

<cstdio>
<cstring>
<clocale>
<cstddef>
<cstdlib>
<ctime>
<cwchar>

....are C library headers. They are standard ISO C++ headers, and
always will be. Indeed, they provide access to some functionality
otherwise impossible to use in standard C++, such as renaming and
deleting files, invoking a command processor, and getting the current
time.

 

[Jack Klein]

On Tue, 11 May 2004 21:34:52 +0200, Karl Heinz Buchegger

[snip]

The real reason why 0 is preferred in C++ is that NULL is an integer
and not a pointer type. This may lead to suprising results in case
of overloaded functions, when suddenly the int version is called and
not the pointer version, as may be expected by someone.
Having said that: I prefer using NULL too, knowing the possible
pitfall.

The macro NULL in C++ is indeed required to expand to an integer
constant expression with the value 0.

On the other hand, the octal literal 0 is also a compile time constant
of type signed int and the value of 0. It is no more a pointer, nor
any less an integer, than the macro NULL.

Can you demonstrate a conforming C++ program where f(NULL) and f(0)
call two different overloaded functions?

 

[Rob Williscroft]

Jack Klein wrote in in
comp.lang.c++:

On Tue, 11 May 2004 21:34:52 +0200, Karl Heinz Buchegger

[snip]

The real reason why 0 is preferred in C++ is that NULL is an integer
and not a pointer type. This may lead to suprising results in case
of overloaded functions, when suddenly the int version is called and
not the pointer version

[snip]


Can you demonstrate a conforming C++ program where f(NULL) and f(0)
call two different overloaded functions?

I Think that was karl's point.

Rob.

 

[Karl Heinz Buchegger]

On Tue, 11 May 2004 21:34:52 +0200, Karl Heinz Buchegger

[snip]

The real reason why 0 is preferred in C++ is that NULL is an integer
and not a pointer type. This may lead to suprising results in case
of overloaded functions, when suddenly the int version is called and
not the pointer version, as may be expected by someone.
Having said that: I prefer using NULL too, knowing the possible
pitfall.

The macro NULL in C++ is indeed required to expand to an integer
constant expression with the value 0.

On the other hand, the octal literal 0 is also a compile time constant
of type signed int and the value of 0. It is no more a pointer, nor
any less an integer, than the macro NULL.

Can you demonstrate a conforming C++ program where f(NULL) and f(0)
call two different overloaded functions?

No I can't and that's the whole point.
Someone using NULL only in pointer contexts exclusively might expect
that.

 

[Karl Heinz Buchegger]

Which pointer type would it be then?

void*

There could be an exception in the language that a void
pointer with a value of 0 is assignable to all other pointers
(but to nothing else then pointers!).
Nearly the same exception as with 0.

 

[Rolf Magnus]

Who said anything about proper? For such a stupid thread, you are now
below it...

if (ptr != 0) //correct, intent not immediately clear

It is to me.

if (*ptr != 0) // intent clear

Why would that be any clearer than the first one?

if (ptr != NULL) // correct, intent is clear

if (*ptr != NULL) // correct, intent is not clear

if (ptr) // correct, intent not immediately clear

I would actually prefer that one.

if (ptr) // if there is an object

if (*ptr != 0) // if the object's value isn't 0

if (*ptr) // intent clear

Again, why is the intent clear, but the intent of "if (ptr)" not? I'd
just say it's the other way round. I know we're talking about opinions
here, so probably none of us can be convinced by the other, but at
least, we could try to understand each other's opinions ;-)

 

[Andre Kostur]

It is to me.

Did the person intend to compare the pointer to 0, or the value of the
int to zero? It's only one missed character away...

Why would that be any clearer than the first one?

Because the programmer has gone through the effort of dereferencing the
pointer first, and thus is likely not trying to compare the pointer
against 0.

IMHO, yes. The Programmer is attempting to compare the pointer.

if (*ptr != NULL) // correct, intent is not clear

This would indicate to me an "error" in that the programmer is attempting
to compare an int with a "pointer".

I would actually prefer that one.

I personally do not like using "implicit booleans" such as the above. I
prefer to explicitly compare against NULL.

if (ptr) // if there is an object

if (*ptr != 0) // if the object's value isn't 0

IMHO: not to me (OK, not immediately). Again, I prefer to explicitly
state the comparison instead of implicitly having the 0 converted to
false.

Again, why is the intent clear, but the intent of "if (ptr)" not? I'd
just say it's the other way round. I know we're talking about opinions
here, so probably none of us can be convinced by the other, but at
least, we could try to understand each other's opinions ;-)

I do have to agree with your argument here. if "if (int(0))" is clear,
then so is "if ((void *)0)"....

Oh, and I prefer using NULL to 0 in pointer contexts. Just reinforces
that you are dealing with pointers instead of integer constants. My
$0.02.

 

[Stephen Waits]

if (ptr != 0) //correct, intent not immediately clear

Not clear to you?

if (ptr) // correct, intent not immediately clear

Most clear to me..

if (*ptr) // intent clear

The idea of the OP is to check the non-zero-ness of a pointer. How does
dereferencing it do anyone any good?

Again.. COMPLETELY MORONIC THREAD..

--Steve

[It's style people.. Bjarne says it himself, though he prefers "0" over
"NULL"]

 

[Julie]

Not clear to you?

If the code is correct, then it is clear. If the code is suspect, then explain
to me how it is clearly differentiable between that and:

if (*ptr != 0)

If there is a potential bug at the first version, there is absolutely no way
that you can determine what the original author's intent is/was w/o comments or
careful examination of the surrounding context.

Something such as:

if (ptr != NULL)

leaves a *lot* less to interpretation as it is much more clear as to what the
original author intended because NULL is typically reserved for pointer use.

Just so that it is clear to you -- the number 0 can be used for:

- a numeric value

***OR***

- a pointer value

Other than sharing the same digit, they have absolutely NO relationship to each
other, and can lead to confusion and/or misinterpretation. If you don't agree,
that is your business, the fact remains regardless.

Most clear to me..


The idea of the OP is to check the non-zero-ness of a pointer. How does
dereferencing it do anyone any good?

Again.. COMPLETELY MORONIC THREAD..

If you are going to make blanket assertions as to the suitability of this
thread, you will need to back it up. What relevant, substantive, and objective
basis do you have for your 'moronic' statement? If you don't appreciate or
tolerate free discussion, please leave, this is an open community, and
assertions such as yours have absolutely no place here.

 

[Mabden]

If you are going to make blanket assertions as to the suitability of this
thread, you will need to back it up. What relevant, substantive, and objective
basis do you have for your 'moronic' statement? If you don't appreciate or
tolerate free discussion, please leave, this is an open community, and
assertions such as yours have absolutely no place here.

Agreed. Stephen is missing the whole point. Julie is right.

Julie snipped this bit (after the sig):

[It's style people.. Bjarne says it himself, though he prefers "0" over

"NULL"]

Yes, he does state a preference for 0. Bjarne obviously wasn't aware of the
OP arguments. NULL is a valid and useful device for pointing out the
difference between setting a value and negating a pointer. Perhaps his
desire to eliminate older C style issues led him towards this false
"improvement".

"NULL" is as useful as "if (5 == x)" in catching bugs; it is a little
unusual at first glance, but if it finds a single hard-to-find bug then it
is worth it's weight in code.

I've met Bjarne twice and now I wish I had this issue to ask him about.
("about which to ask him"? I hate bad English but...)

 

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

Yes, he does state a preference for 0. Bjarne obviously wasn't aware of
the OP arguments. NULL is a valid and useful device for pointing out the
difference between setting a value and negating a pointer. Perhaps his

I have seen many people using NULL with chars (perhaps by influence of the
ascii char name NUL? ). Then you can't always be sure of the intention of
the programmer when you see "if (some_var == NULL)".

 

[Julie]

I have seen many people using NULL with chars (perhaps by influence of the
ascii char name NUL? ). Then you can't always be sure of the intention of
the programmer when you see "if (some_var == NULL)".

Definitely true.

In my opinion, NULL or null should have been added intrinsically to the
language as a generic pointer type (assign to pointer, comparison), and nothing
else. Null Assignment to char would be a compiler error, only 0 or '\0' should
be permitted for 'nul' termination.

Regardless, I don't see the committee adding an intrinsic null to the language
-- seems to me that they are more interested in adding (bloating?) libraries
(i.e. boost?) than fiddling w/ the language... Don't bother correcting me on
this opinion, as I'm only a very casual observer, and am pretty comfortable in
my relative ignorance of the process.