NULL macro vs. 0 as null pointer?

[Ken]

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?

Thanks!

Ken

[Siemel Naran]

"Ken" <kk****@yahoo.com> wrote in message

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?

There's no reason. NULL is more commonplace whereas 0 looks like an
integer, but people use both ways all the time.

I think in C NULL is defined as 0. In C++ it is (void*)0.

[jeffc]

"Ken" <kk****@yahoo.com> wrote in message
news:51**************************@posting.google.c om...

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?

Yes. The value is 0. Why do we need an abstraction of that? Sometimes
abstractions help, but in this case I don't see what's more clear than 0.
Let's say you did this
#define ONE 1

Then in your code you did this

int x = ONE;

Does this help you in any way? What would happen if the value of ONE
changed someday? Normally you'd only want such a macro if the value of some
"magic number" actually were going to change in the future, or in some other
environment or platform, or if the name was somehow much more meaningful
than the number. I think it would be a really really bad idea to change the
value of ONE, ever, and it certainly isn't any more readable than "1".

[Julie]

Siemel Naran wrote:

"Ken" <kk****@yahoo.com> wrote in message

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?

I think in C NULL is defined as 0. In C++ it is (void*)0.

Other way around.

[Andre Kostur]

kk****@yahoo.com (Ken) wrote in news:510b0c84.0407230734.72e84355
@posting.google.com:

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?

Thanks!

Well... somewhat thorny issue (let the religious war begin!). According
to the Standard, 0 is the thing to use. I prefer to use NULL. One of
the original drawbacks was that NULL wasn't #defined to be a simple 0.
It would be #defined to other things like "(void*)0".

I prefer to use NULL to keep the reminder that I'm dealing with a
pointer, and not a simple integral type. Then again, I also despise
writing any implicit boolean checks, except against a bool type.
Example, I hate to write:

char * cp;

if (cp)
{
// do stuff
}
I will always explicitly check against NULL:

if (cp != NULL)
Same for integers.

[Julie]

Ken wrote:

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?

There is no right answer, and from an 'enforcement' standpoint, you will only
cause problems.

If you are simply asking for yourself, you will need to decide what suits you
best.

The general thoughts are:

- NULL can make it more clear in the code that you are expecting and dealing
with pointers, but NULL is not part of the language proper, but part of the
library (meaning that you must include a library before it is defined).

- 0 requires no support library (i.e. it is part of the language proper), but
it can lead some loss of code clarity when dealing w/ pointers (specifically
integer pointers, is the intent to compare the pointer or the destination of
the pointer?)

[Rolf Magnus]

Julie wrote:

Siemel Naran wrote:

"Ken" <kk****@yahoo.com> wrote in message

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

I think in C NULL is defined as 0. In C++ it is (void*)0.

Other way around.

Still not right. In C, it can be either.

[Rolf Magnus]

Ken wrote:

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?

The usage of NULL can produce unexpected results if you are not fully
aware that it is the same as 0.
The following program for instance will print "int":

#include <iostream>
#include <cstdlib>

void x(int i)
{
std::cout << "int\n";
}

void x(char* c)
{
std::cout << "char*\n";
}

int main()
{
x(NULL);
}

When you use NULL, this might be a surprise (thinking of NULL as a
pointer), whereas with 0, it's clear that the int version is used.

[Zilsch]

For your information:

The new keyword is coming: "nullptr"
All new C++ code is encouraged to use "nullptr" instead of 0 or NULL
though the old convention (0/NULL) will continue to be supported for
backwards compatibility

See:
http://std.dkuug.dk/jtc1/sc22/wg21/d...2003/n1488.pdf

[Julie]

Zilsch wrote:

For your information:

The new keyword is coming: "nullptr"
All new C++ code is encouraged to use "nullptr" instead of 0 or NULL
though the old convention (0/NULL) will continue to be supported for
backwards compatibility

See:
http://std.dkuug.dk/jtc1/sc22/wg21/d...2003/n1488.pdf

Good -- if it makes it in.

[JKop]

Ken posted:

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?

Thanks!

Ken

I myself prefer

#define WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK 0
int main()
{
int* p_j = WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK;
}
-JKop

[Julie]

JKop wrote:

Ken posted:

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?

Thanks!

Ken

I myself prefer

#define WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK 0

int main()
{
int* p_j = WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK;
}

-JKop

For US English:

#define WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_BARF \
WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK

[Zilsch]

> Good -- if it makes it in.

"when" it makes it in

You can think it is decided.

[Victor Bazarov]

Julie wrote:

JKop wrote:

Ken posted:

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?

Thanks!

Ken

I myself prefer

#define WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK 0

int main()
{
int* p_j = WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK;
}

-JKop

For US English:

#define WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_BARF \
WHATS_YELLOW_AND_SMELLS_OF_BANANAS____MONKEY_SICK

This produces undefined behaviour because it has double underscores
in the identifier thus making it reserved.

V

[Default User]

jeffc wrote:

"Ken" <kk****@yahoo.com> wrote in message
news:51**************************@posting.google.c om...

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?

Yes. The value is 0. Why do we need an abstraction of that? Sometimes
abstractions help, but in this case I don't see what's more clear than 0.
Let's say you did this
#define ONE 1

Then in your code you did this

int x = ONE;

That's a poor example. A better one would be one common in the old days
of C before boolean types:

#define TRUE 1

Here you are creating a macro because there is some conceptual
difference in the way it's used.

Similarly, the reason for defining a NULL macro is because there's a
conceptual difference between the integer 0 and a null pointer. There's
no particular reason why 0 has to be the null pointer, it's merely
convention.

There is a preference in C++ to use 0 vs. NULL.

Brian Rodenborn

[JKop]

Victor Bazarov posted:

This produces undefined behaviour because it has double underscores in the identifier thus making it reserved.

V

It doesn't contain double underscores, it contains single
underscores and quadruple underscore. A quadruple
underscore is no more two double underscores than a tandum
bike is two bikes.

-JKop

[jeffc]

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

int x = ONE;
That's a poor example. A better one would be one common in the old days
of C before boolean types:

#define TRUE 1

Here you are creating a macro because there is some conceptual
difference in the way it's used.

That's a fine example.
Similarly, the reason for defining a NULL macro is because there's a
conceptual difference between the integer 0 and a null pointer.

I disagree. A pointer holds a numeric value., and 0 means something. It
would take a different sort of object to represent something more
sophisticated (like bool does.) In lieu of that, I think NULL is an
unnecessary abstraction. What mean is precisely 0. Contrast this with the
TRUE example above - what we mean is non-FALSE, or non-zero. There's no
numeric equivalent to that. It's a concept that can't be expressed well
with a specific numeric value.

[jeffc]

"JKop" <NU**@NULL.NULL> wrote in message
news:uJ*****************@news.indigo.ie...

It doesn't contain double underscores, it contains single
underscores and quadruple underscore. A quadruple
underscore is no more two double underscores than a tandum
bike is two bikes.

It is if the preprocessor ignores everything after the first 2 underscores
wrt to naming rules.

[Andre Kostur]

"jeffc" <no****@nowhere.com> wrote in news:41********@news1.prserv.net:

Similarly, the reason for defining a NULL macro is because there's a
conceptual difference between the integer 0 and a null pointer.

I disagree. A pointer holds a numeric value., and 0 means something.
It would take a different sort of object to represent something more
sophisticated (like bool does.) In lieu of that, I think NULL is an
unnecessary abstraction. What mean is precisely 0. Contrast this
with the TRUE example above - what we mean is non-FALSE, or non-zero.
There's no numeric equivalent to that. It's a concept that can't be
expressed well with a specific numeric value.

OK, this may simply be an argumentative answer, but if a pointer only holds
"a numeric value", then why have pointer types at all? Why not just use
unsigned long (or whatever may make sense for the target platform)? To me,
a pointer and a numeric value are two separate beasts. Granted, you can do
some aritmetic operations on a pointer value... but I still thing of them
as different things.

[Default User]

jeffc wrote:

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

Similarly, the reason for defining a NULL macro is because there's a
conceptual difference between the integer 0 and a null pointer.

I disagree. A pointer holds a numeric value., and 0 means something.

Yes, but it doesn't mean "invalid" necessarily. A null pointer isn't
really "true" or "false", it's a memory location. It just so happens
that in C they decided to make the value 0 mean invalid. They could have
picked something else, but 0 is a nice easy number.
It
would take a different sort of object to represent something more
sophisticated (like bool does.) In lieu of that, I think NULL is an
unnecessary abstraction. What mean is precisely 0.

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.

Brian Rodenborn

[Francis Abraham]

There is no advantage to use a constant rather than a meaningful macro
defined for it.

Instead, macros will give you an idea about what the constant stands for in
that context.

"Ken" <kk****@yahoo.com> wrote in message
news:51**************************@posting.google.c om...

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?

Thanks!

Ken

[kk_oop]

After reading all the responses, I'm still not understanding what Stroustrup's means when he says (section
5.1.1, The C++ Programming Language):

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

One thing I have learned is that "0" in a pointer context means
something very specific to an ANSI C++ compiler. It will cause the
compiler to generate the target machine's version of a "null pointer",
whatever that may be (which may or may not be 0). But if a NULL macro
is set to 0, I just don't understand why Stroustrup would have a problem
with it. He does go on to recommend that if NULL must be used, it
should be a const instead of a macro, e.g., const int NULL = 0, so that
NULL can't be redefined. Perhaps the answer is there. If you use a
macro, some third party include file might redefine null to be something
like (void*)0, which would result in unexpected C++ behavior. Still,
even if that happened, wouldn't such use of the redefined NULL cause a
compiler error in C++ if you tried to assign it to a pointer that was
not type (void *)? Maybe the risk is if you use NULL in a condition
check, e.g., "if somePointer == NULL", instead of getting a compile
error, you just would not get TRUE if the pointer was indeed the null
pointer, so your program would compile, but not run as expected?.

Any thoughts?

Thanks,

Ken
Ken wrote:

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?

Thanks!

Ken

[Victor Bazarov]

"kk_oop<no spam> @yahoo.com>" <"kk_oop<no spam> wrote...

After reading all the responses, I'm still not understanding what Stroustrup's means when he says (section 5.1.1, The C++ Programming Language):
[...]

Perhaps you should read more. Go to http://groups.google.com/ and
search for "0 vs NULL pointer" in all the comp.lang.c++.* newsgroups.

The subject has been discussed to death, and there is no really any
reason to do it again. If you don't understand it, _you_ need to
make an effort to first exhaust all available sources of information
and only then post again. Please do so.

V

[Zilsch]

Hi Sir, looks like you just didn't get the kk_oop's question

[kk_oop]

Victor Bazarov wrote:

"kk_oop<no spam> @yahoo.com>" <"kk_oop<no spam> wrote...

After reading all the responses, I'm still not understanding what

Stroustrup's means when he says (section

5.1.1, The C++ Programming Language):
[...]

Perhaps you should read more. Go to http://groups.google.com/ and
search for "0 vs NULL pointer" in all the comp.lang.c++.* newsgroups.

The subject has been discussed to death, and there is no really any
reason to do it again. If you don't understand it, _you_ need to
make an effort to first exhaust all available sources of information
and only then post again. Please do so.

V

With all due respect, the responses to my question and varying opinions
seem to indicate that this subject is far from having concensus,
regardless of what prior posts may be out there. Also, the number of
thoughtful responses my post received justifies the asking of the
question. Feel free to just not respond to posts that are of no
interest to you and let others post/respond as they see fit.

And, of course, have a nice day. :)

Ken

[Victor Bazarov]

"kk_oop<no spam> @yahoo.com>" <"kk_oop<no spam> wrote in message
news:41**********************@news.rcn.com...
<<
V
With all due respect, the responses to my question and varying opinions seem
to indicate that this subject is far from having concensus, regardless of
what prior posts may be out there. Also, the number of thoughtful responses
my post received justifies the asking of the question. Feel free to just
not respond to posts that are of no interest to you and let others
post/respond as they see fit.

And, of course, have a nice day. :)

Ken

Ken,

Are you looking for consensus regarding what BS meant when he said
that he prefers using 0 instead of NULL? Nobody but BS truly knows
the answer to that. You can e-mail him directly, if you didn't know.

The current "consensus" is that there will be a new keyword in C++
relatively soon: 'nullptr', which should take away most (if not all)
of misunderstanding NULL and 0 produce. I can see how it might be
that you can't wait, but nobody can do anything about it. Any
perpetuation of the NULL vs 0 discussion is only useful when it
somehow contributes to the resolution of the issue. Otherwise it
is nothing but waste of bandwidth. That's just my opinion, of course.

Oh, and feel free to refrain from telling me how to behave myself in
an unmoderated forum. I post as I see fit (just like anybody else
here) and if I see fit to recommend reading the archives, I will, no
matter what you think about my interest to other posts. Got it?

And, of course, have a nice day.

V

[Gary Labowitz]

> Ken,

<<big snip>>
And, of course, have a nice day.

Well done, Victor
--
Gary

[kk_oop]

Victor Bazarov wrote:

"kk_oop<no spam> @yahoo.com>" <"kk_oop<no spam> wrote in message
news:41**********************@news.rcn.com...
<<
V
Otherwise it
is nothing but waste of bandwidth.
Apparently you consider harrassing someone with a reasonable question to
be a good use of bandwidth?
Oh, and feel free to refrain from telling me how to behave myself in
an unmoderated forum.
Isn't that what you were doing to me?
I post as I see fit (just like anybody else
here) and if I see fit to recommend reading the archives, I will, no
matter what you think about my interest to other posts. Got it?

Take a chill boss. We're all in this together, and we really all care
about figuring out the same things. That's all I've got to say on about
that, but feel free to harrass me further, since this is, after all, an
unmoderated forum. ;)

See ya,

Ken

[Kelsey Bjarnason]

[snips]

I think in C NULL is defined as 0. In C++ it is (void*)0.

If that were the case, you'd need an explicit cast in C++ to assign NULL
to any non-void pointer - which doesn't appear to be the case.

In _C_ you can get away with using either 0 or (void *)0; in C++ you'd
need to simply use 0.

[kk_oop]

Hi. For anyone still interested, here's my humble conclusion (not thee
conclusion, just my conclusion :) ):

Eventually C++ will have a constant called nullptr. At that time,
that's the thing to use for null pointer values.

Until then, 0 is preferred over the NULL macro since some third party
library could easily provide a NULL macro under the sheets that sets
NULL to (void *)0, as per C. This could inadvertently redefine one's
own NULL that is set to 0. One would hope that a "macro redefinition"
warning would occur in that case, but even if it does, confusion is
bound to occur. Regardless of the macro redef warning, in C++, a type
error would occur if (void *)0 snuck in and was set to a type other than
(void *). I think that's what BS was referring to in regards to C++ and
type checking. Using the constant 0 solves these problems.

Note that BS's recommendation to use const int NULL = 0 doesn't work.
If a NULL macro is being included (as it will be under the sheets in
most cases), the preprocessor will change const int NULL = 0 to
something like"const int 0 = 0" or "const int (void *)0 = 0", neither of
which compiles.

Also, according to the C++ standard, when 0 is set into a pointer, it
does not result in address 0 being generated in the object code. It
actually will result in the target system's null pointer value to be
generated, which may or may not be 0. So according to the C++ standard,
the constant 0, when used as a pointer rvalue, is really an abstraction
for null pointer.

Lastly, when using 0 as a null pointer, one must heed Steve Meyers
recommendation to not allow the same method to be overloaded with an
integer and a pointer. If you do that, programmer confusion will occur
if a 0 constant is used as a parameter (the C++ program will not be
confused--it will assume an integer--but the programmer will easily be
confused by the resulting behavior if he were assuming the parameter to
be treated as a null pointer).

Thanks to all for your varied and interesting thoughts. It's what makes
these newsgroups invaluable. :)

See ya,

Ken

Ken wrote:

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?

Thanks!

Ken

[Mabden]

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

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.

But I am in the camp that sides with (void *)0. NULL should be a pointer.
You are assigning to a pointer, so it should be assigned _as_ a pointer. Not
as an integer. Not as Zero.

char *p = NULL;

To me, that says set pointer P to be a null pointer. IOW, not just pointing
off into space, but to a location that means "not yet assigned".

if (p == NULL)
something(p);

To me, that says "if the pointer P is not assigned, do something to p".
This lets me know that P has not yet been "pointed" to a valid location.

if (*p == 0)
something(p);

To me, that says "if the pointer P's value is 0, do something to p".

I would assume in the second case that P was pointing to a valid location
that happened to have a zero in it.

It's a subtle difference, but the best bugs are subtle. It's better to
prevent misunderstandings by being explicit, especially amongst a group of
programmers.

I hope I said what I mean correctly, if not please, no flames.

--
Mabden

[Victor Bazarov]

"Mabden" <mabden@sbc_global.net> wrote...

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

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.

But I am in the camp that sides with (void *)0. NULL should be a pointer.

You're in a C++ newsgroup, if you didn't notice.

[Mabden]

"kk_oop<no spam> @yahoo.com>" <"kk_oop<no spam> wrote in message
news:41**********************@news.rcn.com...

Any thoughts?

Um, "don't top-post".

[Mabden]

And have a nice day! :-)

[Mabden]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:ZaYMc.29307$8_6.22208@attbi_s04...

"Mabden" <mabden@sbc_global.net> wrote...

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

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.

But I am in the camp that sides with (void *)0. NULL should be a

pointer.
You're in a C++ newsgroup, if you didn't notice.

WTF?!! No I didn't, honestly. Was this cross-posted at some point?
Oh well, I still disagree with the Great BS, himself, and prefer a pointer
to point to a pointer. NULL should be (void *)0. Until another construct
comes along that assures that:
int i = NULL;
is not a valid statement.

So there. ;-p

--
Mabden

[kk_oop]

See responses below...

Mabden wrote:

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

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/d...2003/n1488.pdf

<start of excerpt>
The current C++ standard provides the special rule that 0 is both an
integer constant and a null pointer constant. From [C++03] clause 4.10:

A null pointer constant is an integral constant expression (expr.const)
rvalue of integer type that evaluates to zero. A null pointer constant
can be converted to a pointer type; the result is the null pointer value
of that type and is distinguishable from every other value of pointer to
object or pointer to function type.
<end of excerpt>

So in C++, using 0 for the NULL pointer is more than just a convention.
It is part of the language definition. Note that C is quite different.
From the same article:

<start of excerpt>
The C standard [C99] says (clause 6.3.2.3): An integer constant
expression with the value 0, or such an expression cast to type void *,
is called a null pointer constant.[55] If a null pointer constant is
converted to a pointer type, the resulting pointer, called a null
pointer, is guaranteed to compare unequal to a pointer to any object or
function.
<end of excerpt>

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

I hope that helps--without flames :).

See ya,

Ken

[kk_oop]

Mabden wrote:

"kk_oop<no spam> @yahoo.com>" <"kk_oop<no spam> wrote in message
news:41**********************@news.rcn.com...

Any thoughts?

Um, "don't top-post".

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

[kk_oop]

Mabden wrote:

WTF?!! No I didn't, honestly. Was this cross-posted at some point?
I hope Victor sees it in his heart to forgive this transgression. :)
Oh well, I still disagree with the Great BS, himself, and prefer a pointer
to point to a pointer. NULL should be (void *)0. Until another construct
comes along that assures that:
int i = NULL;
is not a valid statement.

So there. ;-p

The problem is that in C++, if you try to set a pointer that is not type
(void *) equal to (void *)0, you will get a compile error saying that
the lvalue and rvalue are incompatible. That would not happen in C.

See ya,

Ken

[Karl Heinz Buchegger]

"kk_oop" wrote:

Mabden wrote:

WTF?!! No I didn't, honestly. Was this cross-posted at some point?

I hope Victor sees it in his heart to forgive this transgression. :)

Oh well, I still disagree with the Great BS, himself, and prefer a pointer
to point to a pointer. NULL should be (void *)0. Until another construct
comes along that assures that:
int i = NULL;
is not a valid statement.

So there. ;-p

The problem is that in C++, if you try to set a pointer that is not type
(void *) equal to (void *)0,

It could have been made different in the language.
After all when I write:

int* p = 0;

I am assigning an integer to a pointer. Compared to that,
the issue of allowing to assign (or compare) a void pointer
with a constant value of ((void*)0) to assign or compare to
any other pointer type is the far lesser evil. At least the
whole statement then would deal with pointers only and not with
a mix of pointers and integers.

Just my 2 cents.

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

[Andre Kostur]

"Mabden" <mabden@sbc_global.net> wrote in
news:rl***************@newssvr27.news.prodigy.com:

Oh well, I still disagree with the Great BS, himself, and prefer a

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

[jeffc]

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

It
would take a different sort of object to represent something more
sophisticated (like bool does.) In lieu of that, I think NULL is an
unnecessary abstraction. What mean is precisely 0.

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]

jeffc wrote:

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

It
would take a different sort of object to represent something more
sophisticated (like bool does.) In lieu of that, I think NULL is an
unnecessary abstraction. What mean is precisely 0.

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.

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

[Default User]

Mabden wrote:

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

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.

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

[Mabden]

"kk_oop<no spam> @yahoo.com>" <"kk_oop<no spam> wrote in message news:41**********************@news.rcn.com...

Mabden wrote:

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

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

[Mabden]

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

Mabden wrote:

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

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.

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]

"kk_oop<no spam> @yahoo.com>" <"kk_oop<no spam> wrote in message news:41**********************@news.rcn.com...
Mabden wrote:

"kk_oop<no spam> @yahoo.com>" <"kk_oop<no spam> wrote in message
news:41**********************@news.rcn.com...
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]

"Andre Kostur" <nn******@kostur.net> wrote in message
news:Xn*******************************@207.35.177. 134...

"Mabden" <mabden@sbc_global.net> wrote in
news:rl***************@newssvr27.news.prodigy.com:

Oh well, I still disagree with the Great BS, himself, and prefer a

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!

--
Mabden

[Default User]

Mabden wrote:

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]

"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...

Mabden wrote:

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

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.

--
Mabden

[Ioannis Vranos]

Ken wrote:

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