Usage of C++ NULL vs 0

[muktipada]

Hello,

As a C++ developer which one we should use for pointer assignment,
NULL or 0.

typedef DummyC DummyClass*; // in some header file.

DummyC obj = NULL;

if (obj == NULL) {
// It gives an impression that obj is a pointer
}

OR

DummyC obj = 0;

if (obj == 0) {
// it gives an impression that obj is an integer, which is not true.
}

I understand NULL is a macro and defined to 0. But for readibility
purpose should
we use NULL for poiner. and 0 for integer.

Also since system provide NULL to be defined to some value(today it is
0) and if
tomorrow the defined value changes, then still our code will be
portable
if we use NULL. So I think instead of using hard coaded value 0, we
should
use NULL for pointer. It increases both for readbility and
portability. Any suggestion?

Regards,
-mukti

[Victor Bazarov]

muktipada wrote:

Hello,

As a C++ developer which one we should use for pointer assignment,
NULL or 0.

typedef DummyC DummyClass*; // in some header file.

I believe you meant

typedef DummyClass * DummyC;

>
DummyC obj = NULL;

if (obj == NULL) {
// It gives an impression that obj is a pointer
}

OR

DummyC obj = 0;

if (obj == 0) {
// it gives an impression that obj is an integer, which is not true.
}

I understand NULL is a macro and defined to 0. But for readibility
purpose should
we use NULL for poiner. and 0 for integer.

Use 'NULL' because when 'nullptr' becomes part of the language, it would
be much easier to do a search-and-replace.

>
Also since system provide NULL to be defined to some value(today it is
0) and if
tomorrow the defined value changes, then still our code will be
portable
if we use NULL. So I think instead of using hard coaded value 0, we
should
use NULL for pointer. It increases both for readbility and
portability. Any suggestion?

Don't strain your brain about the "system provide NULL to be defined"
thing. The Standard says that NULL is a null pointer constant
expression. Right now it is an expression that evaluates to 0 (it can
be, e.g. (123-123) ). Whatever the "system provide" cannot be different
from that, really.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[puzzlecracker]

On Jul 25, 8:02*am, Victor Bazarov <[e-mail]:

muktipada wrote:

Hello,

As a C++ developer which one we should use for pointer assignment,
NULL or 0.

typedef DummyC DummyClass*; // in some header file.

I believe you meant

* * *typedef DummyClass * DummyC;

DummyC obj = NULL;

if (obj == NULL) {
*// It gives an impression that obj is a pointer
}

OR

DummyC obj = 0;

if (obj == 0) {
// it gives an impression that obj is an integer, which is not true.
}

I understand NULL is a macro and defined to 0. But for readibility
purpose should
we use NULL for poiner. and 0 for integer.

Use 'NULL' because when 'nullptr' becomes part of the language, it would
be much easier to do a search-and-replace.

Also since system provide NULL to be defined to some value(today it is
0) and if
tomorrow the defined value changes, then still our code will be
portable
if we use NULL. So I think instead of using hard coaded value 0, we
should
use NULL for pointer. It increases both for readbility and
portability. Any suggestion?

Don't strain your brain about the "system provide NULL to be defined"
thing. *The Standard says that NULL is a null pointer constant
expression. *Right now it is an expression that evaluates to 0 (it can
be, e.g. (123-123) ). *Whatever the "system provide" cannot be different
from that, really.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Isn't true that in C, NULL has a slightly different meaining -1?

If you code is still working with C components, that might cause issues

[Joe Greer]

puzzlecracker <ir*********@gmail.comwrote in news:f2184114-7967-4215-
84***************@h17g2000prg.googlegroups.com:

>I do not respond to top-posted replies, please don't ask

Isn't true that in C, NULL has a slightly different meaining -1?

If you code is still working with C components, that might cause issues

I don't know what the latest standard says, but it at least used to be true
that in C NULL was ((void *)0) At least on some systems. This is illegal
in C++.

joe

[Matthias Buelow]

muktipada wrote:

As a C++ developer which one we should use for pointer assignment,
NULL or 0.

For assignment, I use 0 (in both C and C++) and usually !p for testing
for a null pointer. IMHO "NULL" is ugly and probably just a workaround
left over from the days when assigning 0 to pointers could have caused
type problems.

[Juha Nieminen]

muktipada wrote:

As a C++ developer which one we should use for pointer assignment,
NULL or 0.

Many C++ developers prefer 0 because it avoids the need to #include
whichever header NULL was defined in.

The only situation where using 0 as null pointer might cause ambiguity
problems is in overloading situations like this:

void foo(int i);
void foo(SomeType*);

int main()
{
foo(0); // ambiguous
}

In practice the int version of the function will be called (although
I'm not 100% sure what the standard says about this), which might not be
what the programmer wanted.

A properly-implemented NULL would avoid the ambiguity. Rather oddly,
though, the NULL macro in many compilers still cause ambiguity, and a
"foo(NULL);" will call the int version regardless (gcc at least issues a
warning, though).

[Greg Comeau]

In article <bc**********************************@q28g2000prh. googlegroups.com>,
muktipada <mu**************@gmail.comwrote:

>As a C++ developer which one we should use for pointer assignment,
NULL or 0.

typedef DummyC DummyClass*; // in some header file.

DummyC obj = NULL;

if (obj == NULL) {
// It gives an impression that obj is a pointer
}

OR

DummyC obj = 0;

if (obj == 0) {
// it gives an impression that obj is an integer, which is not true.

Saying that is debatable, but I'll sidestep the debate and only say
it is debatable.

>}

I understand NULL is a macro and defined to 0.

Maybe it is.

>But for readibility purpose should
we use NULL for poiner. and 0 for integer.

Again maybe.

>Also since system provide NULL to be defined to some value(today it is
0) and if tomorrow the defined value changes, then still our code will be
portable if we use NULL.

Actually no, NULL does not fully accomodate all NULL'ness (ugh)
considerations in either C or C++.

>So I think instead of using hard coaded value 0,
we should use NULL for pointer. It increases both for readbility and
portability. Any suggestion?

Some thoughts:
http://www.comeaucomputing.com/techtalk/#NULL
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Greg Comeau]

In article <f2**********************************@h17g2000prg. googlegroups.com>,
puzzlecracker <ir*********@gmail.comwrote:

>Isn't true that in C, NULL has a slightly different meaining -1?

What NULL is defined as (in C or C++) is implementation-defined,
although in C++ a few more definitions are ruled out.
You are probably thinking of EOF but that's implementation-defined too.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Victor Bazarov]

Juha Nieminen wrote:

muktipada wrote:

>As a C++ developer which one we should use for pointer assignment,
NULL or 0.

Many C++ developers prefer 0 because it avoids the need to #include
whichever header NULL was defined in.

In the real life that header is very often already included directly or
indirectly. I strongly doubt that the need to include <cstddefis the
real reason.

The only situation where using 0 as null pointer might cause ambiguity
problems is in overloading situations like this:

void foo(int i);
void foo(SomeType*);

int main()
{
foo(0); // ambiguous

Ambiguous? Not at all! The literal 0 has the type 'int'.

}

In practice the int version of the function will be called (although
I'm not 100% sure what the standard says about this), which might not be
what the programmer wanted.

Regardless of what the programmer wanted (the compilers can't read
minds, at least *yet*), the Standard is perfectly OK with it and there
is no ambiguity.

A properly-implemented NULL would avoid the ambiguity.

The macro 'NULL' is a remnant from C times. It should be abolished. As
soon as the new Standard is out, there will be 'nullptr' keyword which
will help "disambiguate" the situation, so to speak.

BTW, what's "a properly-implemented NULL"? Have you seen one?

Rather oddly,
though, the NULL macro in many compilers still cause ambiguity,

Here you go with that "ambiguity" claim again. What compilers are
those? Name at least one that in the code you provided reports any
ambiguity if you change 'foo(0)' to 'foo(NULL)'. At least *one*. I am
very curious.

and a
"foo(NULL);" will call the int version regardless (gcc at least issues a
warning, though).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Bo Persson]

muktipada wrote:

Hello,

As a C++ developer which one we should use for pointer assignment,
NULL or 0.

typedef DummyC DummyClass*; // in some header file.

DummyC obj = NULL;

if (obj == NULL) {
// It gives an impression that obj is a pointer
}

OR

DummyC obj = 0;

if (obj == 0) {
// it gives an impression that obj is an integer, which is not true.
}

If so, perhaps the problem is that 'obj' isn't a very good name for a
variable?

Does

if (NumberOfElements == NULL)
{

}

also give the impression that NumberOfElements is a pointer? No.

>
I understand NULL is a macro and defined to 0. But for readibility
purpose should
we use NULL for poiner. and 0 for integer.

Maybe, maybe not.

Many C++ programmers tries to avoid macros, especially when they don't
do anything useful.
Bo Persson

[Juha Nieminen]

Victor Bazarov wrote:

>Rather oddly,
though, the NULL macro in many compilers still cause ambiguity,

Here you go with that "ambiguity" claim again. What compilers are
those? Name at least one that in the code you provided reports any
ambiguity if you change 'foo(0)' to 'foo(NULL)'. At least *one*. I am
very curious.

gcc gives the following warning when NULL is used in this case:

warning: passing NULL to non-pointer argument 1 of 'void foo(int)'

I suppose that the idea behind the warning is "the C++ standard
requires me to call the int version of foo(), but since you are passing
NULL, it looks quite suspicious, and probably not what you intended".

(Note that gcc *always* gives this warning, even if no warning options
have been specified.)

[Victor Bazarov]

Juha Nieminen wrote:

Victor Bazarov wrote:

>>Rather oddly,
though, the NULL macro in many compilers still cause ambiguity,

Here you go with that "ambiguity" claim again. What compilers are
those? Name at least one that in the code you provided reports any
ambiguity if you change 'foo(0)' to 'foo(NULL)'. At least *one*. I am
very curious.

gcc gives the following warning when NULL is used in this case:

warning: passing NULL to non-pointer argument 1 of 'void foo(int)'

I suppose that the idea behind the warning is "the C++ standard
requires me to call the int version of foo(), but since you are passing
NULL, it looks quite suspicious, and probably not what you intended".

(Note that gcc *always* gives this warning, even if no warning options
have been specified.)

Is there some more text to the warning that you're not showing? Because
I can't find the word "ambiguity" or "ambiguous" anywhere.

Here is an example of ambiguous call:

void foo(char);
void foo(long);
int main() {
foo(0); // ambiguous!
}

Test it with your version of gcc, see what it says.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Fraser Ross]

It says in N2214:
// Partial specialization cases
template<typename Tclass X { };
template<typename Tclass X<T*X { }; // case X<T*>
The second X there must be a mistake.

template<typename Tclass X<T::*X { }; // case X<T::*>
Same again there.

X<nullptr_tx; // error, ambiguous; nullptr_t is both a pointer
// and pointer-to-member type, so it's undecidable which
// partial specialization to use

Is it possible to use explicit qualification to resolve this case and if
so what is the syntax? I think the answer is probably no and this is a
weak spot.

Fraser.

[Fraser Ross]

"Fraser Ross"

template<typename Tclass X<T::*X { }; // case X<T::*>

template<typename T, typename Cclass X<T C::*X { };

Thats a partial specialisation for X with a pointer to a data member of
C of type T. The paper doesn't make sense.

Fraser.

[James Kanze]

On Jul 25, 1:39 pm, muktipada <[e-mail]:

As a C++ developer which one we should use for pointer
assignment, NULL or 0.

typedef DummyC DummyClass*; // in some header file.

That won't compile. I think you mean:

typedef DummyClass* DummyC ;

DummyC obj = NULL;

if (obj == NULL) {
// It gives an impression that obj is a pointer
}

OR

DummyC obj = 0;

if (obj == 0) {
// it gives an impression that obj is an integer, which is not true.
}

I understand NULL is a macro and defined to 0. But for
readibility purpose should we use NULL for poiner. and 0 for
integer.

That is a major unanswered question. Using NULL correctly
indicates intent, but some people object on the grounds that the
compiler doesn't understand that intent, e.g.:

void f( char const* ) ;
void f( int ) ;

f( NULL ) ; // Calls f( int )...

I use NULL, but I also don't overload when it makes a difference
which function will be called. (I'll give the functions
different names.) If you like all of your functions to have the
same name, with the semantics of the program depending on
overload resolution, then NULL is probably not a good idea.

Also since system provide NULL to be defined to some
value(today it is 0) and if tomorrow the defined value
changes, then still our code will be portable if we use NULL.

The standard requires the macro NULL to be defined as a null
pointer constant. Any null pointer constant you use, NULL, 0,
(1-1), '\0', etc. will work the same as far as the comiler is
concerned.

So I think instead of using hard coaded value 0, we should use
NULL for pointer. It increases both for readbility and
portability. Any suggestion?

It doesn't affect portability. I agree with regards to
readability, but opinions differ on the question, and I don't
think that there is a "right" answer. (Well, there is, sort of:
the next version of the standard will have a null_ptr, which
will work the way it should.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 25, 2:44 pm, puzzlecracker <[e-mail]:

On Jul 25, 8:02 am, Victor Bazarov <[e-mail]:

muktipada wrote:

[...]

Don't strain your brain about the "system provide NULL to be
defined" thing. The Standard says that NULL is a null
pointer constant expression. Right now it is an expression
that evaluates to 0 (it can be, e.g. (123-123) ). Whatever
the "system provide" cannot be different from that, really.

Isn't true that in C, NULL has a slightly different meaining -1?

No. Both languages require NULL to be defined as a "null
pointer constant", and both require "null pointer constants" to
work in the same way. Standard C (but not traditional C) does
allow more liberty in what is considered a null pointer
constant, but that's not really relevant; if you compile your
C++ code as C++, and your C code as C, there won't be any
problems.

If you code is still working with C components, that might
cause issues

Such as?

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 25, 3:45 pm, Matthias Buelow <[e-mail]:

muktipada wrote:

As a C++ developer which one we should use for pointer assignment,
NULL or 0.

For assignment, I use 0 (in both C and C++) and usually !p for
testing for a null pointer. IMHO "NULL" is ugly and probably
just a workaround left over from the days when assigning 0 to
pointers could have caused type problems.

I think you've got it backwards. C++ is a typed language, and
you should say what you mean. In particular, a conditional
should have type bool, rather than count on some obscure
implicit conversions. The use of 0 for a null pointer is a
hang-over from C, where the authors forgot to provide a proper
null pointer constant (probably because the language was
evolving from B, which didn't have a bool type---or any types,
for that matter). The next release of the C++ standard will
correct this oversight.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 25, 4:15 pm, Juha Nieminen <[e-mail]:

muktipada wrote:

As a C++ developer which one we should use for pointer assignment,
NULL or 0.

Many C++ developers prefer 0 because it avoids the need to
#include whichever header NULL was defined in.

Now that's the worse reason I've heard to date:-). Many C++
developers prefer NULL, because at least with some compilers,
accidentally using it as an integral type will provoke a
warning.

The only situation where using 0 as null pointer might cause
ambiguity problems is in overloading situations like this:

void foo(int i);
void foo(SomeType*);

int main()
{
foo(0); // ambiguous

Totally unabiguous. It calls foo(int).

The problem here, of course (and the major argument against
NULL), is that f(NULL) is also unambiguous... and calls
foo(int). But as I said, good compilers (well, at least g++)
will warn in this case.

}

In practice the int version of the function will be called
(although I'm not 100% sure what the standard says about
this), which might not be what the programmer wanted.

A properly-implemented NULL would avoid the ambiguity. Rather
oddly, though, the NULL macro in many compilers still cause
ambiguity, and a "foo(NULL);" will call the int version
regardless (gcc at least issues a warning, though).

Nothing odd about it; it's what the standard requires (for
historical reasons). But as you say, g++ warns.

More bothersome are cases like:

template< typename T >
void f( T ) ;

where you don't know which instantiation you'll get with NULL
(although you know that T will be an integral type).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 25, 4:47 pm, [e-mail] (Greg Comeau) wrote:

In article
<[e-mail]>,

[...]

Actually no, NULL does not fully accomodate all NULL'ness
(ugh) considerations in either C or C++.

But it comes a lot closer in C. (You're right to have
mentionned C, though, since it brings up the case which hasn't
been mentionned yet: var args. Where if the function is
expecting a pointer, neither NULL nor 0 work.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Greg Comeau]

In article <3b**********************************@34g2000hsh.g ooglegroups.com>,
James Kanze <ja*********@gmail.comwrote:

>On Jul 25, 4:47 pm, [e-mail] (Greg Comeau) wrote:

>In article
<[e-mail]>,

[...]

>Actually no, NULL does not fully accomodate all NULL'ness
(ugh) considerations in either C or C++.

But it comes a lot closer in C. (You're right to have
mentionned C, though, since it brings up the case which hasn't
been mentionned yet: var args. Where if the function is
expecting a pointer, neither NULL nor 0 work.)

I probably see it as a wash. Since C (at least C89) has issues
with func decls with unspecified args on its side, missing (implicit)
eturn types, etc., though, they're not unique to just NULL gyrations.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Fraser Ross]

Is anyone interested in this? This could be the partial specialisation
example:

template<typename T>
class X {};

template<typename T>
class X<T*{}; //1

template<typename T, typename C>
class X<T C::*{}; //2

X<nullptr_tx;

When there is only 1 and not 2, does nullptr_t become the type for T?

When there is only 2 and not 1, does nullptr_t become the type for both
T and C?
Fraser.

[Matthias Buelow]

James Kanze wrote:

I think you've got it backwards. C++ is a typed language, and
you should say what you mean. In particular, a conditional
should have type bool, rather than count on some obscure
implicit conversions. The use of 0 for a null pointer is a
hang-over from C, where the authors forgot to provide a proper
null pointer constant (probably because the language was
evolving from B, which didn't have a bool type---or any types,
for that matter). The next release of the C++ standard will
correct this oversight.

I don't like verbosity and bureaucracy in programming languages. The
static typing in C++ is a means to an end and not something to worship
for its own sake. I think, checking if a pointer is "valid" in some
context is clearer conceptually than any technicalities in expressing
whether it has a value of a particular type. Too much useless detail
there (that's a frequent complaint I have with C++ but at least in a few
situations, one can do things better without the compiler barfing all
over the place, at least still. No doubt this will be "fixed" sometime,
too.)

[Matthias Buelow]

James Kanze wrote:

evolving from B, which didn't have a bool type---or any types,

Ah, just to stoke the fire a bit.. I don't like boolean types, either
:). I think C got it right in the first try.

[James Kanze]

On Jul 27, 2:26 pm, Matthias Buelow <[e-mail]:

James Kanze wrote:

I think you've got it backwards. C++ is a typed language, and
you should say what you mean. In particular, a conditional
should have type bool, rather than count on some obscure
implicit conversions. The use of 0 for a null pointer is a
hang-over from C, where the authors forgot to provide a proper
null pointer constant (probably because the language was
evolving from B, which didn't have a bool type---or any types,
for that matter). The next release of the C++ standard will
correct this oversight.

I don't like verbosity and bureaucracy in programming languages. The
static typing in C++ is a means to an end and not something to worship
for its own sake. I think, checking if a pointer is "valid" in some
context is clearer conceptually than any technicalities in expressing
whether it has a value of a particular type.

But you can't check whether a pointer is valid; you just have to
know. (I agree that it would be nice if pointers had an
isValid() member function, but they don't.)

Too much useless detail there (that's a frequent complaint I
have with C++ but at least in a few situations, one can do
things better without the compiler barfing all over the place,
at least still. No doubt this will be "fixed" sometime, too.)

Well, it does require you do know what you're doing. I'd hardly
call that a disadvantage, however.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Matthias Buelow]

James Kanze wrote:

But you can't check whether a pointer is valid; you just have to
know.

Yes.. what I mean is that in the language context, where a non-null
pointer is used to indicate an "valid" pointer:

if (p) vs. if (NULL != p).

I find the first form more meaningful and it hides the detail that the
pointer has the value NULL, a technicality which I'm not really
interested in here.

(I agree that it would be nice if pointers had an
isValid() member function, but they don't.)

if (p) vs. if (p.isValid()) ?

I think I prefer the first.

Well, it does require you do know what you're doing. I'd hardly
call that a disadvantage, however.

IMHO the disadvantage is that one can easily get bogged down in a level
of detail that distracts from the problem I actually want to solve.
Maybe it's just me but a significant time of my C++ programming is spent
fighting the compiler. However, YMMV. Maybe my mental model just doesn't
map well onto C++. Curiously, I don't really have these problems with C,
though, although it is a more primitive language (but it is honest, and
doesn't pretend to be high-level.)

[Bo Persson]

Matthias Buelow wrote:

James Kanze wrote:

>But you can't check whether a pointer is valid; you just have to
know.

Yes.. what I mean is that in the language context, where a non-null
pointer is used to indicate an "valid" pointer:

if (p) vs. if (NULL != p).

That's one of the cases to test for.

>
I find the first form more meaningful and it hides the detail that
the pointer has the value NULL, a technicality which I'm not really
interested in here.

>(I agree that it would be nice if pointers had an
isValid() member function, but they don't.)

if (p) vs. if (p.isValid()) ?

I think I prefer the first.

But it doesn't answer the question that the second one would (if it
was available):

T* p = new T();
delete p;

if (p.isValid())
{
// p still points to a valid object
}

>

>Well, it does require you do know what you're doing. I'd hardly
call that a disadvantage, however.

IMHO the disadvantage is that one can easily get bogged down in a
level of detail that distracts from the problem I actually want to
solve. Maybe it's just me but a significant time of my C++
programming is spent fighting the compiler. However, YMMV. Maybe my
mental model just doesn't map well onto C++. Curiously, I don't
really have these problems with C, though, although it is a more
primitive language (but it is honest, and doesn't pretend to be
high-level.)

Having just a small hammer and a screwdriver makes it simpler to
master one's tools. A skilled craftsman ("knowing what he is doing"),
can be much more productive with a nail gun or a chain saw.
Bo Persson

[Matthias Buelow]

Bo Persson wrote:

Having just a small hammer and a screwdriver makes it simpler to
master one's tools. A skilled craftsman ("knowing what he is doing"),
can be much more productive with a nail gun or a chain saw.

However, a skilled craftsman knows when to use a chainsaw and when to
use a nail file.

[.rhavin grobert]

On 25 Jul., 15:15, Joe Greer <[e-mail]:

I don't know what the latest standard says, but it at least used to be true
that in C NULL was ((void *)0) At least on some systems. This is illegal
in C++.

What makes this expression illegal? Looks like a pretty good way to
distinguish an integer from a pointer for the compiler...

-.rhavin;)

[Joe Greer]

".rhavin grobert" <cl***@yahoo.dewrote in
news:02**********************************@26g2000h sk.googlegroups.com:

On 25 Jul., 15:15, Joe Greer <[e-mail]:

>I don't know what the latest standard says, but it at least used to
be true that in C NULL was ((void *)0) At least on some systems.
This is illegal in C++.

What makes this expression illegal? Looks like a pretty good way to
distinguish an integer from a pointer for the compiler...

-.rhavin;)

Probably the wrong choice or words, but the standard defines NULL to be 0
therefore it would be nonconformant if it were (void *)0.

joe

[Pete Becker]

On 2008-07-28 10:47:51 -0400, ".rhavin grobert" <cl***@yahoo.desaid:

On 25 Jul., 15:15, Joe Greer <[e-mail]:

>I don't know what the latest standard says, but it at least used to be true
that in C NULL was ((void *)0) At least on some systems. This is illegal
in C++.

What makes this expression illegal? Looks like a pretty good way to
distinguish an integer from a pointer for the compiler...

int *ip = (void*)0; // error: can't convert void* to int*

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Greg Comeau]

In article <02**********************************@26g2000hsk.g ooglegroups.com>,
..rhavin grobert <cl***@yahoo.dewrote:

>On 25 Jul., 15:15, Joe Greer <[e-mail]:

>I don't know what the latest standard says, but it at least used to be true
that in C NULL was ((void *)0) At least on some systems. This is illegal
in C++.

What makes this expression illegal? Looks like a pretty good way to
distinguish an integer from a pointer for the compiler...

The C++ standard makes it clear that ((void *)0) as NULL is a no-go.
Why, because void * to T * is an implicit conversion in C but is
not in C++. Forcing casts on every use of NULL is not a reasonable
request. Blah blah.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[James Kanze]

On Jul 28, 11:23 pm, [e-mail] (Greg Comeau) wrote:

In article <[e-mail]>,

.rhavin grobert <[e-mail]:

On 25 Jul., 15:15, Joe Greer <[e-mail]:

I don't know what the latest standard says, but it at least used to betrue
that in C NULL was ((void *)0) At least on some systems. This is illegal
in C++.

What makes this expression illegal? Looks like a pretty good way to
distinguish an integer from a pointer for the compiler...

The C++ standard makes it clear that ((void *)0) as NULL is a
no-go. Why, because void * to T * is an implicit conversion
in C but is not in C++. Forcing casts on every use of NULL is
not a reasonable request. Blah blah.

It's not quite that simple. The C++ standard makes it clear
that ((void*)0) is not a null pointer constant, and the C
standard makes it clear that it is. But null pointer constants
are special cases. Compiler magic, in sum. And the standard
could literally do anything here.

Note that in C, the following is not guaranteed:

int i0 = 0 ;
void* p = (void*)i0 ;
assert( p == ((void*)0) ) ;

The conversion of a null pointer constant is a special case, and
obeys different rules than other conversions. Historically, the
null pointer constant is 0, going back to B. Why Kernighan and
Richie didn't introduce a special keyword for it, when he
introduced typing (going from B to C), I don't know; the use of
0 was obviously "wrong" even back then. (They probably meant
to, but didn't get around to it until it was too late.) Given
the estabilished use of 0, why the standards (C or C++) allowed
other things (like (1-1) or 0UL---or in the case of C,
((void*)0)) is also beyond me. If they were going to change
something (from just 0), they should have introduced a keyword.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 28, 1:15 pm, Matthias Buelow <[e-mail]:

Bo Persson wrote:

Having just a small hammer and a screwdriver makes it
simpler to master one's tools. A skilled craftsman ("knowing
what he is doing"), can be much more productive with a nail
gun or a chain saw.

However, a skilled craftsman knows when to use a chainsaw and
when to use a nail file.

A skilled craftsman also knows the difference between a hammer
and a screwdriver. Or between a pointer and a bool, in the case
at hand.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Matthias Buelow]

James Kanze wrote:

I don't know; the use of
0 was obviously "wrong" even back then.

K&R come from a strong theoretical background; using the value 0 for
invalid pointers is perfectly fine and elegant -- certainly nicer than
fumbling about with special clunky "nullptr" verbosity. That is, unless
you come across a platform where pointers cannot be initialized to all
bits zero. However, imho, one should rather keep the language clean than
embellish it in dubious ways just to acommodate weird architectures. So
augmenting the language to allow interpreting 0 as not-all-bits-zero on
some platforms is a perfectly sound choice, imho, and seems to be the
minimal change necessary to support those environments. If you don't
like it, don't use these architectures. :)

[Matthias Buelow]

Bo Persson wrote:

But it doesn't answer the question that the second one would (if it
was available):

T* p = new T();
delete p;

if (p.isValid())
{
// p still points to a valid object
}

Another example:

T *p;
// is p initialized?

At least most compilers warn of uninitialized variables. However, why
isn't it initialized to some sensible value (like 0)? This is another
example, where C++' claim to be a high-level language just doesn't match
reality. You can either live with it being a macro assembler (just like
C) with considerably more icing on top (compared to C), or delude
yourself and run into problems all the way. I prefer the first approach
and it works reasonably well under that assumption. Botching it with
isValid() and similar hacks trying to give it the appearance of being
anything but a macro assembler won't work, imho.

[Matthias Buelow]

James Kanze wrote:

A skilled craftsman also knows the difference between a hammer
and a screwdriver. Or between a pointer and a bool, in the case
at hand.

The fundamental flaw of bool is that one can't map n-ary logic onto the
binary Boolean one. I often had to change bool to something else in
function returns because all of a sudden, I had to return more than just
true/false and still check for truth. Thankfully that still works in
C++. IMHO, bool is just useless.

[Ian Collins]

Matthias Buelow wrote:

Bo Persson wrote:

>But it doesn't answer the question that the second one would (if it
was available):

T* p = new T();
delete p;

if (p.isValid())
{
// p still points to a valid object
}

Another example:

T *p;
// is p initialized?

At least most compilers warn of uninitialized variables. However, why
isn't it initialized to some sensible value (like 0)?

Isn't that why we declare and initialise our variables when we need them?

--
Ian Collins.

[Ian Collins]

Matthias Buelow wrote:

James Kanze wrote:

>A skilled craftsman also knows the difference between a hammer
and a screwdriver. Or between a pointer and a bool, in the case
at hand.

The fundamental flaw of bool is that one can't map n-ary logic onto the
binary Boolean one. I often had to change bool to something else in
function returns because all of a sudden, I had to return more than just
true/false and still check for truth. Thankfully that still works in
C++. IMHO, bool is just useless.

Maybe C++ could borrow from PHP and have an === (exactly equal to)
operator? Then we could return true, false or NULL.

--
Ian Collins.

[Bo Persson]

Matthias Buelow wrote:

Bo Persson wrote:

>But it doesn't answer the question that the second one would (if it
was available):

T* p = new T();
delete p;

if (p.isValid())
{
// p still points to a valid object
}

Another example:

T *p;
// is p initialized?

At least most compilers warn of uninitialized variables. However,
why isn't it initialized to some sensible value (like 0)?

Benchmarks! :-)

The blessing and the curse of C++ is C compatibility. If C++ were to
initialize variables where C is not, we would be flooded with silly
benchmarks showing that C code is faster than identical C++. And they
would be right!

This is
another example, where C++' claim to be a high-level language just
doesn't match reality. You can either live with it being a macro
assembler (just like C) with considerably more icing on top
(compared to C), or delude yourself and run into problems all the
way. I prefer the first approach and it works reasonably well under
that assumption.

C++ is a pragmatic way of creating a powerful high level language.
It's inheritance is what made it take off.

I have used other languages like Simula, Modula-2/3, and Ada. Quite
nice for their time, but never really took of. Not even with billions
in fundings, like in the last case.

Botching it with isValid() and similar hacks
trying to give it the appearance of being anything but a macro
assembler won't work, imho.

I am not asking for that either. The C++ solution (to mostly
everything) is to put the pointer in a managing class. The manager
will know and/or make sure that the pointer is valid.
Bo Persson

[anon]

Matthias Buelow wrote:

minimal change necessary to support those environments. If you don't
like it, don't use these architectures. :)

Sometimes you do not have a choice (unless you wanted to change a job ;) )

[ajonesfl]

I understand NULL is a macro and defined to 0. But for readibility
purpose should
we use NULL for poiner. and 0 for integer.

Also since system provide NULL to be defined to some value(today it is
0) and if
tomorrow the defined value changes, then still our code will be
portable
if we use NULL. So I think instead of using hard coaded value 0, we
should
use NULL for pointer. It increases both for readbility and
portability. Any suggestion?

To answer your questions concerning using NULL or 0, I would agree
with the the creator of the language Bjarne Stroustrup. He mentions
this specifically in his book The C++ Programming Language in section
5.1.1 and again in section 5.8. His advice is "Use 0 rather than
NULL". This is a direct quote from his book. If you read section 5.1.1
he explains why....

-Adam J.

[James Kanze]

On Jul 29, 10:24 am, Matthias Buelow <[e-mail]:

James Kanze wrote:

I don't know; the use of
0 was obviously "wrong" even back then.

K&R come from a strong theoretical background;

K&R were adapting B to support types, since some sort of typing
is needed on a byte addressable architecture (at least if you
are to use byte addressing). B was totally untyped. And there
was never the least bit of "theoretical" in C; C is a succession
of ad hoc solutions to problems that were actually encountered.

using the value 0 for invalid pointers is perfectly fine and
elegant -- certainly nicer than fumbling about with special
clunky "nullptr" verbosity. That is, unless you come across a
platform where pointers cannot be initialized to all bits
zero.

I've worked on platforms where all zero bits were valid
pointers. At least by the time they'd published, K&R made it
quite plain that using 0 for pointers was a hack, and that it
required some fancy games with the type system to make it work.

But that's a different problem. We're talking about using a
pointer where a boolean value is required. In a typed language:
a conversion. In a strongly typed language, implicit
conversions are an anathema. So the question really boils down
to whether you want strict static typing or not (or rather, to
what degree, because of course, it's not a black and white
question). In this regard, I agree with the original
proposition for adding a bool type: all of the implicite
conversions to bool should have been deprecated from the start.
The long term evolution of C++ is striving to increase static
type safety. (Note that Stroustrup was responsible for large
scale development, or something like that, at Bell Labs. The
larger the project, the more important static type checking
becomes.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 29, 11:37 am, "Bo Persson" <[e-mail]:

[...]

C++ is a pragmatic way of creating a powerful high level
language. It's inheritance is what made it take off.

It's its pragmatics (C compatibility, works with existing
linkers, etc.) which made it succeed. It certainly wasn't the
only (or even the first) language to propose inheritance.

I have used other languages like Simula, Modula-2/3, and Ada.
Quite nice for their time, but never really took of. Not even
with billions in fundings, like in the last case.

In the last case, the language probably didn't take of because
of the funding, or the source of the funding. I know of one or
two cases where Ada wasn't considered because it was backed by a
government burocracy.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Nick Keighley]

On 29 Jul, 09:39, Matthias Buelow <[e-mail]:

James Kanze wrote:

A skilled craftsman also knows the difference between a hammer
and a screwdriver. *Or between a pointer and a bool, in the case
at hand.

The fundamental flaw of bool is that one can't map n-ary logic onto the
binary Boolean one.

The fundamental problem of int is that one can't map floating point
values
onto the integral Integer ones

I often had to change bool to something else in
function returns because all of a sudden, I had to return more than just
true/false and still check for truth.

this very rarely happens to me. I think you are misusing bool.
I use bool for predicates so my bool funnctions are called things like

is_valid(), is_used(), has_hit(), empty(), equal(), event_occurred()
etc.

Thankfully that still works in C++.

what works in C++?

IMHO, bool is just useless.

it's just find for representing booleans
--
Nick Keighley

[James Kanze]

On Jul 29, 10:39 am, Matthias Buelow <[e-mail]:

James Kanze wrote:

A skilled craftsman also knows the difference between a hammer
and a screwdriver. Or between a pointer and a bool, in the case
at hand.

The fundamental flaw of bool is that one can't map n-ary logic
onto the binary Boolean one.

Which is why we have a type bool, and operators which explicitly
return a bool.

I often had to change bool to something else in function
returns because all of a sudden, I had to return more than
just true/false and still check for truth.

But what is the truth, in such cases? You've radically changed
the contract of a function. The last thing you want is for
existing client code to compile without change; you want to be
forced to look at that code, to ensure that it will still work
with the new contract.

Thankfully that still works in C++.

Just the opposite. You've just set forward an incredibly strong
argument against the implicit conversion of bool. One that
hadn't occurred to me (because I generally don't allow myself
the liberty of changing the contract of a function, once it is
used in client code).

IMHO, bool is just useless.

But you just proved the contrary.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Bo Persson]

James Kanze wrote:

On Jul 29, 11:37 am, "Bo Persson" <[e-mail]:

[...]

>C++ is a pragmatic way of creating a powerful high level
language. It's inheritance is what made it take off.

It's its pragmatics (C compatibility, works with existing
linkers, etc.) which made it succeed. It certainly wasn't the
only (or even the first) language to propose inheritance.

I meant that its inheritance from C was a big part of its initial
success. Not inheritance as a language element...

>

>I have used other languages like Simula, Modula-2/3, and Ada.
Quite nice for their time, but never really took of. Not even
with billions in fundings, like in the last case.

In the last case, the language probably didn't take of because
of the funding, or the source of the funding. I know of one or
two cases where Ada wasn't considered because it was backed by a
government burocracy.

:-)
Bo Persson

[Matthias Buelow]

James Kanze wrote:

The
larger the project, the more important static type checking
becomes.)

This is too simplistic, imho. The larger the project, the more highlevel
the language should be. Getting bogged down in technical detail (like
the extremely verbose, explicit C++ style of typing) is more of a threat
than lack of compile-time type safety. Generally speaking, the more
suitable a language is to describe the problem (or its solution) in a
concise, clear way, the less bugs the software will have and the less
problems will arise during maintenance. C++ has some provisions here,
for example STL containers and algorithms vs. C-style pointer juggling
but in other parts it is completely off the trail.

[Matthias Buelow]

James Kanze wrote:

The last thing you want is for
existing client code to compile without change; you want to be
forced to look at that code, to ensure that it will still work
with the new contract.

Wrong, this is _exactly_ the thing I want to have. If I make a local
change, including changing return types or parameters, the least thing I
want to do is having to go to all call places and change call/value
semantics there aswell. This is just tedious and annoying and
discourages quick and frequent changes, which are essential for a
"malleable" development process. I mean, it's bad (and silly) enough
that I have to recompile all call places when I make such a change.

[Francis Litterio]

Matthias Buelow wrote:

James Kanze wrote:

>The last thing you want is for
existing client code to compile without change; you want to be
forced to look at that code, to ensure that it will still work
with the new contract.

Wrong, this is _exactly_ the thing I want to have. If I make a local
change, including changing return types or parameters, the least thing I
want to do is having to go to all call places and change call/value
semantics there aswell.

^^^^^^^^^

So where is your line? How much of the semantics of an interface do you
want to be able to change _without_ the compiler telling you that the
change might break client code? Do you want to be able to change

int f() { ... }

to:

double f() { ... }

without a compiler telling you that your clients might be affected
negatively?

You _do_ want the compiler to diagnose client breakage at some point,
right?
--
Fran

[Francis Litterio]

Ian Collins wrote:

Matthias Buelow wrote:

>Another example:

T *p;
// is p initialized?

At least most compilers warn of uninitialized variables. However, why
isn't it initialized to some sensible value (like 0)?

Isn't that why we declare and initialise our variables when we need them?

Yes, but C and C++ are schizophrenic: file-scope and static local
variables are implicitly initialized to all-bits-zero, but automatic
variables are not.

IMHO, not initializing automatic variables is premature optimization.
Yes, those cycles may have been precious in 1971, but today spending a
few CPU cycles to initialize an automatic variable worth saving the far
more valuable minutes or hours of human time needed to track down the
bug (not to mention potentially avoiding customer exposure to the bug).
--
Fran