By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,147 Members | 1,402 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,147 IT Pros & Developers. It's quick & easy.

not null

P: n/a


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;

}

}

}
Jul 22 '05 #1
Share this Question
Share on Google+
36 Replies


P: n/a

"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
Jul 22 '05 #2

P: n/a
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.
Jul 22 '05 #3

P: n/a
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.
Jul 22 '05 #4

P: n/a
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."

Jul 22 '05 #5

P: n/a
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.

Jul 22 '05 #6

P: n/a
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.
Jul 22 '05 #7

P: n/a
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.
Jul 22 '05 #8

P: n/a
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.
Jul 22 '05 #9

P: n/a
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?
Jul 22 '05 #10

P: n/a
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.
Jul 22 '05 #11

P: n/a
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.
Jul 22 '05 #12

P: n/a
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.
Jul 22 '05 #13

P: n/a
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
Jul 22 '05 #14

P: n/a
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?
Jul 22 '05 #15

P: n/a
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?

Jul 22 '05 #16

P: n/a
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
Jul 22 '05 #17

P: n/a
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).
Jul 22 '05 #18

P: n/a
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
Jul 22 '05 #19

P: n/a
JKop wrote:

This conversation is so stupid!!!


Agree. Borderline retarded.

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

--Steve
Jul 22 '05 #20

P: n/a
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.
Jul 22 '05 #21

P: n/a
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.
Jul 22 '05 #22

P: n/a
> 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
Jul 22 '05 #23

P: n/a
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.
Jul 22 '05 #24

P: n/a
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
Jul 22 '05 #25

P: n/a
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
Jul 22 '05 #26

P: n/a
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
Jul 22 '05 #27

P: n/a
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/
Jul 22 '05 #28

P: n/a
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
Jul 22 '05 #29

P: n/a
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
Jul 22 '05 #30

P: n/a
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 ;-)

Jul 22 '05 #31

P: n/a
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.
Jul 22 '05 #32

P: n/a
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"]
Jul 22 '05 #33

P: n/a
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.
Jul 22 '05 #34

P: n/a
"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
Jul 22 '05 #35

P: n/a
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
Jul 22 '05 #36

P: n/a
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.
Jul 22 '05 #37

This discussion thread is closed

Replies have been disabled for this discussion.