not null

[John J]

The following code is complete and working within a class; however, it uses
"e" as a pointer to an Entry object without checking if that it is not null.
This of course doesn't matter if objects are created correctly; however, it
will probably cause a problem should the "e" be null. Is there a simple
means I can use to check that "e" is not null?

Thanks for any help

//Find the winner

void Race::winner (ostream& out) const

{

Entry* e = NULL;

if (nEntries == 0)

{

out << "No entries" << endl;

}

else

{

bool found_a_winner = false; // no winner found
yet

for (int i=0; i<nEntries; i++)

{

e = entries[i];

if (e->getPlace() == 1)

{

out << "The winner is: " << endl;

out << *e;

found_a_winner = true; // a winner has been
found

}

}

if (!found_a_winner) // if no winner

{

out << "No winner was found in this
race" << endl;

}

}

}

[John Harrison]

"John J" <...@...> wrote in message
news:d4******************************@news.teranew s.com...

The following code is complete and working within a class; however, it uses "e" as a pointer to an Entry object without checking if that it is not null. This of course doesn't matter if objects are created correctly; however, it will probably cause a problem should the "e" be null. Is there a simple
means I can use to check that "e" is not null?

Yes the code you had before

if (e)
{
// e is not null
}
else
{
// e is null
}

was perfectly correct. However I would say this isn't the right place to
test for it. It is when the object is created that you should be checking if
it is created correctly. The way you can report any error as soon as it
happens.

john

[Jacques Labuschagne]

John Harrison wrote:

if (e)
{
// e is not null

Or even
if (e != NULL){
...
}
which is of course equivalent to (and clearer than)
if (e != 0){
...
}

Regards,
Jacques.

[Bill Seurer]

Jacques Labuschagne wrote:

Or even
if (e != NULL){
...
}
which is of course equivalent to (and clearer than)
if (e != 0){
...
}

NULL is from some of the C includes and is not a base part of the
language. 0 is correct.

[David Rubin]

John J wrote:

The following code is complete and working within a class; however, it uses
"e" as a pointer to an Entry object without checking if that it is not null.
This of course doesn't matter if objects are created correctly; however, it
will probably cause a problem should the "e" be null. Is there a simple
means I can use to check that "e" is not null?
[snip] void Race::winner (ostream& out) const

{

Entry* e = NULL;

[snip - get e from an array of pointers and use it]

As John Harrison indicated, this is not the right place to validate e.
However, if it is "impossible by design" for e to be null at this point
in your program, you should assert() or throw an exception to indicate
that something has gone drastically wrong.

/david

--
"As a scientist, Throckmorton knew that if he were ever to break wind in
the echo chamber, he would never hear the end of it."

[Rolf Magnus]

Bill Seurer wrote:

Jacques Labuschagne wrote:

Or even
if (e != NULL){
...
}
which is of course equivalent to (and clearer than)
if (e != 0){
...
}
NULL is from some of the C includes and is not a base part of the
language.

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

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

[Buster]

Rolf Magnus wrote:

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

No. The language is one thing, the libraries another,
even though both are defined by the standard.

0 is correct.

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

Agreed. There are other headers that define NULL too.

--
Regards,
Buster.

[Julie]

Bill Seurer wrote:

Jacques Labuschagne wrote:

Or even
if (e != NULL){
...
}
which is of course equivalent to (and clearer than)
if (e != 0){
...
}

NULL is from some of the C includes and is not a base part of the
language. 0 is correct.

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

Who is this mystery person/committee that can dictate to me what is correct and
clearer? In my experience, comparing pointers to 0 is _not_ more correct or
clearer than comparing to NULL. NULL is much more self-documenting, and much
more cleanly conveys the intent over comparing to 0.

[Buster]

Julie wrote:

Who is this mystery person/committee that can dictate to me what is correct and
clearer?
That straw man, over there in the next field.
In my experience, comparing pointers to 0 is _not_ more correct or
clearer than comparing to NULL. NULL is much more self-documenting, and much
more cleanly conveys the intent over comparing to 0.

Either you mean "In my opinion", or you're the despot. I like '0'.

--
Regards,
Buster.

[Julie]

Buster wrote:

Julie wrote:

Who is this mystery person/committee that can dictate to me what is correct and
clearer?

That straw man, over there in the next field.

In my experience, comparing pointers to 0 is _not_ more correct or
clearer than comparing to NULL. NULL is much more self-documenting, and much
more cleanly conveys the intent over comparing to 0.

Either you mean "In my opinion", or you're the despot. I like '0'.

No, I mean "in my experience", and I'm not the despot.

Do you feel that comparing to zero is more _self_documenting_ than comparing to
NULL irrespective of your preference?

How do you conversationally discuss such pointers? Do you say: 'the pointer is
null' or 'the pointer is zero', or something else?

[Buster]

Julie wrote:

Buster wrote:

In my experience, comparing pointers to 0 is _not_ more correct or
clearer than comparing to NULL. NULL is much more self-documenting, and much
more cleanly conveys the intent over comparing to 0.

Either you mean "In my opinion", or you're the despot. I like '0'.

No, I mean "in my experience", and I'm not the despot.

Do you feel that comparing to zero is more _self_documenting_ than comparing to
NULL irrespective of your preference?

Neither more nor less, in my opinion.
How do you conversationally discuss such pointers? Do you say: 'the pointer is
null' or 'the pointer is zero', or something else?

The first, of course. Note that "null" is an adjective.

--
Regards,
Buster.

[Bill Seurer]

Julie wrote:

So is your point that NULL is not part of C++???
It is part of some of the header files.
Who is this mystery person/committee that can dictate to me what is correct and
clearer? In my experience, comparing pointers to 0 is _not_ more correct or
clearer than comparing to NULL. NULL is much more self-documenting, and much
more cleanly conveys the intent over comparing to 0.

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.

[Bill Seurer]

Bill Seurer wrote:

Julie wrote:

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

It is part of some of the header files.

Who is this mystery person/committee that can dictate to me what is
correct and
clearer? In my experience, comparing pointers to 0 is _not_ more
correct or
clearer than comparing to NULL. NULL is much more self-documenting,
and much
more cleanly conveys the intent over comparing to 0.

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.

P.S. Read section 5.1.1 of _The C++ Programming Language_ by Stroustrup.

[Karl Heinz Buchegger]

Bill Seurer wrote:

Julie wrote:

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

It is part of some of the header files.

Who is this mystery person/committee that can dictate to me what is correct and
clearer? In my experience, comparing pointers to 0 is _not_ more correct or
clearer than comparing to NULL. NULL is much more self-documenting, and much
more cleanly conveys the intent over comparing to 0.

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.

That's a moot argumentation.
Every real world program includes some system headers.

I could use your argumentation against std::cout also.

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.

--
Karl Heinz Buchegger
kb******@gascad.at

[Julie]

Karl Heinz Buchegger wrote:

Bill Seurer wrote:

Julie wrote:

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

It is part of some of the header files.

Who is this mystery person/committee that can dictate to me what is correct and
clearer? In my experience, comparing pointers to 0 is _not_ more correct or
clearer than comparing to NULL. NULL is much more self-documenting, and much
more cleanly conveys the intent over comparing to 0.

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.

That's a moot argumentation.
Every real world program includes some system headers.

I could use your argumentation against std::cout also.

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.

Has there ever been any discussion of adding NULL to the base language (not as
a manifest constant) where it specifically _is_ a pointer type?

[Rolf Magnus]

Julie wrote:

That's a moot argumentation.
Every real world program includes some system headers.

I could use your argumentation against std::cout also.

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.

Has there ever been any discussion of adding NULL to the base language
(not as a manifest constant) where it specifically _is_ a pointer
type?

Which pointer type would it be then?

[JKop]

Rolf Magnus posted:

Julie wrote:

Has there ever been any discussion of adding NULL to the base language
(not as a manifest constant) where it specifically _is_ a pointer
type?

Which pointer type would it be then?

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!!!!!";
}
---

For Clarity, an "if", "while", "for" statement will execute if the value is
true.

True means "NOT EQUAL TO 0". -5 is true, 's' is true.

False means "EQUAL TO 0". 0 is false. '\0' is false. 0.0 is false. 0x0 is
false. 00 is false.
-JKop

[Julie]

Rolf Magnus wrote:

Julie wrote:

That's a moot argumentation.
Every real world program includes some system headers.

I could use your argumentation against std::cout also.

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.

Has there ever been any discussion of adding NULL to the base language
(not as a manifest constant) where it specifically _is_ a pointer
type?

Which pointer type would it be then?

I don't know, something generic and typeless that can be applied (and only
applied) to anything * (void * on up).

[Juergen Heinzl]

In article <40***************@nospam.com>, Julie wrote:

Bill Seurer wrote:

Jacques Labuschagne wrote:

> Or even
> if (e != NULL){
> ...
> }
> which is of course equivalent to (and clearer than)
> if (e != 0){
> ...
> }

NULL is from some of the C includes and is not a base part of the
language. 0 is correct.

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

[Stephen Waits]

JKop wrote:

This conversation is so stupid!!!

Agree. Borderline retarded.

http://www.research.att.com/~bs/bs_faq2.html#null

--Steve

[Julie]

JKop wrote:

Rolf Magnus posted:

Julie wrote:

Has there ever been any discussion of adding NULL to the base language
(not as a manifest constant) where it specifically _is_ a pointer
type?

Which pointer type would it be then?

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]

Juergen Heinzl wrote:

In article <40***************@nospam.com>, Julie wrote:

Bill Seurer wrote:

Jacques Labuschagne wrote:
> Or even
> if (e != NULL){
> ...
> }
> which is of course equivalent to (and clearer than)
> if (e != 0){
> ...
> }

NULL is from some of the C includes and is not a base part of the
language. 0 is correct.

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]

Jorge Rivera wrote:

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

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]

On Tue, 11 May 2004 14:39:18 +0200, Rolf Magnus <ra******@t-online.de>
wrote in comp.lang.c++:

Bill Seurer wrote:

Jacques Labuschagne wrote:

Or even
if (e != NULL){
...
}
which is of course equivalent to (and clearer than)
if (e != 0){
...
}

NULL is from some of the C includes and is not a base part of the
language.

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

0 is correct.

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
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On Tue, 11 May 2004 13:09:07 -0500, Bill Seurer <se****@us.ibm.com>
wrote in comp.lang.c++:

Julie wrote:

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

It is part of some of the header files.

Who is this mystery person/committee that can dictate to me what is correct and
clearer? In my experience, comparing pointers to 0 is _not_ more correct or
clearer than comparing to NULL. NULL is much more self-documenting, and much
more cleanly conveys the intent over comparing to 0.

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
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On Tue, 11 May 2004 21:34:52 +0200, Karl Heinz Buchegger
<kb******@gascad.at> wrote in comp.lang.c++:

[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?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Rob Williscroft]

Jack Klein wrote in news:8l********************************@4ax.com in
comp.lang.c++:

On Tue, 11 May 2004 21:34:52 +0200, Karl Heinz Buchegger
<kb******@gascad.at> wrote in comp.lang.c++:

[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.
--
http://www.victim-prime.dsl.pipex.com/

[Karl Heinz Buchegger]

Jack Klein wrote:

On Tue, 11 May 2004 21:34:52 +0200, Karl Heinz Buchegger
<kb******@gascad.at> wrote in comp.lang.c++:

[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
kb******@gascad.at

[Karl Heinz Buchegger]

Rolf Magnus wrote:

Julie wrote:

That's a moot argumentation.
Every real world program includes some system headers.

I could use your argumentation against std::cout also.

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.

Has there ever been any discussion of adding NULL to the base language
(not as a manifest constant) where it specifically _is_ a pointer
type?

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.

--
Karl Heinz Buchegger
kb******@gascad.at

[Rolf Magnus]

Julie wrote:

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]

Rolf Magnus <ra******@t-online.de> wrote in news:c7*************@news.t-
online.com:

Julie wrote:

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.

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

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

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.

if (ptr != NULL) // correct, intent is clear
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".
if (ptr) // correct, intent not immediately clear

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

if (*ptr) // intent clear

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]

Julie wrote:

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]

Stephen Waits wrote:

Julie wrote:

if (ptr != 0) //correct, intent not immediately clear
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.

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

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]

"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com...

Stephen Waits wrote:

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

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

--
Mabden

[Julián Albo]

Mabden wrote:

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

--
Salu2

[Julie]

Julián Albo wrote:

Mabden wrote:

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

--
Salu2

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.