www.digitalmars.com         C & C++   DMDScript  

D - null == 0

reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Is there some reason why C++'s equivalence of NULL and 0 was considered not
a good idea?  In porting C++ to D, I end up having to change a lot of 0's to
null.

Just wondering if there's some reason for it or if it's just an oversight.
It would sure be convenient.

Sean
Jun 08 2002
next sibling parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
It could be that it is much better for maintenance.

As in

if(monitor == null)    //    clearly a pointer/reference

if(monitor == 0)    // clearly integral

if(monitor)            // boolean (or should be!)





"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:adu1ee$1fmj$1 digitaldaemon.com...
 Is there some reason why C++'s equivalence of NULL and 0 was considered

 a good idea?  In porting C++ to D, I end up having to change a lot of 0's

 null.

 Just wondering if there's some reason for it or if it's just an oversight.
 It would sure be convenient.

 Sean

Jun 08 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I don't know what maintenance programmers have against using browse info to
look up the declaration of a variable.  When I'm maintaining code I don't
like making that kind of assumption... I'll go look it up to make sure.

Since D doesn't have separate headers, and doesn't need forward declaration,
it keeps definitions closer to their usage point most of the time.  That
helps.

Sean

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:adu2ps$1gtv$1 digitaldaemon.com...
 It could be that it is much better for maintenance.

 As in

 if(monitor == null)    //    clearly a pointer/reference

 if(monitor == 0)    // clearly integral

 if(monitor)            // boolean (or should be!)





 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:adu1ee$1fmj$1 digitaldaemon.com...
 Is there some reason why C++'s equivalence of NULL and 0 was considered

 a good idea?  In porting C++ to D, I end up having to change a lot of


 to
 null.

 Just wondering if there's some reason for it or if it's just an


 It would sure be convenient.

 Sean


Jun 08 2002
parent "Matthew Wilson" <dmd synesis.com.au> writes:
What if you're using browse info? What if (as is common) you're reading the
code on the train between clients?

Surely if there's a way to make something definitive without an onerous
imposition (and here's where we will all debate endlessly) on the original
author, it's worth doing. Java is criticised and often quoted as an example
of an overly patriarchal language, but it is far simpler to maintain (at
least in the regard in which we are discussing) than other languages - Java
just sucks for a lot of other reasons.

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:adu3f4$1hh4$1 digitaldaemon.com...
 I don't know what maintenance programmers have against using browse info

 look up the declaration of a variable.  When I'm maintaining code I don't
 like making that kind of assumption... I'll go look it up to make sure.

 Since D doesn't have separate headers, and doesn't need forward

 it keeps definitions closer to their usage point most of the time.  That
 helps.

 Sean

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:adu2ps$1gtv$1 digitaldaemon.com...
 It could be that it is much better for maintenance.

 As in

 if(monitor == null)    //    clearly a pointer/reference

 if(monitor == 0)    // clearly integral

 if(monitor)            // boolean (or should be!)





 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:adu1ee$1fmj$1 digitaldaemon.com...
 Is there some reason why C++'s equivalence of NULL and 0 was



 not
 a good idea?  In porting C++ to D, I end up having to change a lot of


 to
 null.

 Just wondering if there's some reason for it or if it's just an


 It would sure be convenient.

 Sean



Jun 08 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:adu1ee$1fmj$1 digitaldaemon.com...
 Is there some reason why C++'s equivalence of NULL and 0 was considered

 a good idea?  In porting C++ to D, I end up having to change a lot of 0's

 null.

 Just wondering if there's some reason for it or if it's just an oversight.
 It would sure be convenient.

The idea is that there are some cases where the null pointer might not be 0. I remember this issue from the early C days. The other idea is for type safety, i.e. making it clear you're dealing with a null reference rather than a numerical 0.
Jun 08 2002
next sibling parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
null != 0 - I like that idea (though don't know why yet ...)

type-safety - I like that very much. Very wise. Does this mean that
conditional expressions involving pointers will have to be boolean, ie if(p
!= null) rather than if(p) ?

"Walter" <walter digitalmars.com> wrote in message
news:aduk1j$216b$2 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:adu1ee$1fmj$1 digitaldaemon.com...
 Is there some reason why C++'s equivalence of NULL and 0 was considered

 a good idea?  In porting C++ to D, I end up having to change a lot of


 to
 null.

 Just wondering if there's some reason for it or if it's just an


 It would sure be convenient.

The idea is that there are some cases where the null pointer might not be

 I remember this issue from the early C days.

 The other idea is for type safety, i.e. making it clear you're dealing

 a null reference rather than a numerical 0.

Jun 08 2002
next sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
That's the thing...  it's a lot more typing.  Three more characters.  hehehe

Sean

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:adum9g$23bh$1 digitaldaemon.com...
 null != 0 - I like that idea (though don't know why yet ...)

 type-safety - I like that very much. Very wise. Does this mean that
 conditional expressions involving pointers will have to be boolean, ie

 != null) rather than if(p) ?

 "Walter" <walter digitalmars.com> wrote in message
 news:aduk1j$216b$2 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:adu1ee$1fmj$1 digitaldaemon.com...
 Is there some reason why C++'s equivalence of NULL and 0 was



 not
 a good idea?  In porting C++ to D, I end up having to change a lot of


 to
 null.

 Just wondering if there's some reason for it or if it's just an


 It would sure be convenient.

The idea is that there are some cases where the null pointer might not


 0.
 I remember this issue from the early C days.

 The other idea is for type safety, i.e. making it clear you're dealing

 a null reference rather than a numerical 0.


Jun 09 2002
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:adum9g$23bh$1 digitaldaemon.com...
 Very wise. Does this mean that
 conditional expressions involving pointers will have to be boolean, ie

 != null) rather than if(p) ?

I haven't bought into that yet <g>. I guess I like the shorthand too much.
Jun 09 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
<POKE type=lighthearted dest=Walter>
 Do you also like the
    if(var = 0)
shorthand?

That's an inevitable problem with C's old style...and it would become a syntax
error if you only allowed bools in conditional expressions...
</POKE>



Walter wrote:

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:adum9g$23bh$1 digitaldaemon.com...
 Very wise. Does this mean that
 conditional expressions involving pointers will have to be boolean, ie

 != null) rather than if(p) ?

I haven't bought into that yet <g>. I guess I like the shorthand too much.

-- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Jun 10 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D04B5FB.A1DD2C98 deming-os.org...

 <POKE type=lighthearted dest=Walter>
  Do you also like the
     if(var = 0)
 shorthand?

It is already forbidden in D!
Jun 10 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Two questions:
1) Can you point me to the spec where this is?  I can never find
stuff...
2) How do you do this without creating special-case rules?  One of the
great advantages of C is that it is mostly (if you discount variable &
type declarations) context-free.  If (var = 0) is an expression that
results in an integer, and integers are legal arguments to if(), then
if(var = 0) should be legal.

If you add this inconsistency, you're going to make D parsers and
compilers MUCH harder to write...

Pavel Minayev wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D04B5FB.A1DD2C98 deming-os.org...

 <POKE type=lighthearted dest=Walter>
  Do you also like the
     if(var = 0)
 shorthand?

It is already forbidden in D!

-- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Jun 11 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D0627D9.8F67461A deming-os.org...

 Two questions:
 1) Can you point me to the spec where this is?  I can never find
 stuff...

It isn't in the docs anywhere. Walter mentioned it in the newsgroup twice, as far as I remember. You can try it yourself. =)
 2) How do you do this without creating special-case rules?  One of the
 great advantages of C is that it is mostly (if you discount variable &
 type declarations) context-free.  If (var = 0) is an expression that
 results in an integer, and integers are legal arguments to if(), then
 if(var = 0) should be legal.

I guess there's a special flag that tells whether = was used in an expression. "if" and "while" just check this flag.
 If you add this inconsistency, you're going to make D parsers and
 compilers MUCH harder to write...

Not really, as long as a single flag does the trick.
Jun 11 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Pavel Minayev wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D0627D9.8F67461A deming-os.org...

 Two questions:
 1) Can you point me to the spec where this is?  I can never find
 stuff...

It isn't in the docs anywhere. Walter mentioned it in the newsgroup twice, as far as I remember. You can try it yourself. =)
 2) How do you do this without creating special-case rules?  One of the
 great advantages of C is that it is mostly (if you discount variable &
 type declarations) context-free.  If (var = 0) is an expression that
 results in an integer, and integers are legal arguments to if(), then
 if(var = 0) should be legal.

I guess there's a special flag that tells whether = was used in an expression. "if" and "while" just check this flag.
 If you add this inconsistency, you're going to make D parsers and
 compilers MUCH harder to write...

Not really, as long as a single flag does the trick.

I'm awfully close to a Bison parser that can parse D (it seems as though it can be done, with some tricks). But the nonterminal "expression" now needs to be split into two almost identical nonterminals: "expression" and "expressions_legal_inside_a_conditional_test". Ick. Still, whether you want to scratch my back or not, you have to agree that it violates C's "as context free as possible" rule. It's a bad precedent to set... -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Jun 11 2002
next sibling parent C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
 Pavel Minayev wrote:
 
 
 I'm awfully close to a Bison parser that can parse D (it seems as though
 it
 can be done, with some tricks).  But the nonterminal "expression" now
 needs to be split into two almost identical nonterminals: "expression" and
 "expressions_legal_inside_a_conditional_test".  Ick.

Me too. Instead of using to near identical expressions you could pass a flag in yylval stating wether the expression is valid in a conditional and test that flag if the expression is used in the conditional (this is the way I use to generate warnings in the oomic parser for such expressions). This would move the problem from the parser to the helper code, and could be implemented in a few lines. C 2002/6/11
Jun 12 2002
prev sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D064081.4F84E1F9 deming-os.org...

 I'm awfully close to a Bison parser that can parse D (it seems as though

 can be done, with some tricks).  But the nonterminal "expression" now

 be split into two almost identical nonterminals: "expression" and
 "expressions_legal_inside_a_conditional_test".  Ick.

Can't you define the generic "expression" as a list of "legal_conditional_expressions" separated by assignment ops?
Jun 12 2002
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Pavel Minayev wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D064081.4F84E1F9 deming-os.org...

 I'm awfully close to a Bison parser that can parse D (it seems as though

 can be done, with some tricks).  But the nonterminal "expression" now

 be split into two almost identical nonterminals: "expression" and
 "expressions_legal_inside_a_conditional_test".  Ick.

Can't you define the generic "expression" as a list of "legal_conditional_expressions" separated by assignment ops?

Yeah, but it gets really ugly. -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Jun 12 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D0627D9.8F67461A deming-os.org...
 Two questions:
 1) Can you point me to the spec where this is?  I can never find
 stuff...
 2) How do you do this without creating special-case rules?  One of the
 great advantages of C is that it is mostly (if you discount variable &
 type declarations) context-free.  If (var = 0) is an expression that
 results in an integer, and integers are legal arguments to if(), then
 if(var = 0) should be legal.

 If you add this inconsistency, you're going to make D parsers and
 compilers MUCH harder to write...

This is not in the parser. It is in the semantic analysis phase, where AssignExp's issue an error when asked to convert to boolean (via the checkBoolean() virtual function).
Jun 11 2002
prev sibling next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:advb9n$2ncg$1 digitaldaemon.com...

 Very wise. Does this mean that
 conditional expressions involving pointers will have to be boolean, ie

 != null) rather than if(p) ?

I haven't bought into that yet <g>. I guess I like the shorthand too much.

Oh yes! Please PLEASE PLEASE keep it! =)
Jun 10 2002
prev sibling parent reply "Matthew Wilson" <dm synesis-group.com> writes:
What do you think about having a compiler option "-pendantic" for
practioners of the true way ... sorry, I mean pedantic sods like me?

"Walter" <walter digitalmars.com> wrote in message
news:advb9n$2ncg$1 digitaldaemon.com...
 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:adum9g$23bh$1 digitaldaemon.com...
 Very wise. Does this mean that
 conditional expressions involving pointers will have to be boolean, ie

 != null) rather than if(p) ?

I haven't bought into that yet <g>. I guess I like the shorthand too much.

Jun 10 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <dm synesis-group.com> wrote in message
news:ae3gtl$11dq$1 digitaldaemon.com...
 What do you think about having a compiler option "-pendantic" for
 practioners of the true way ... sorry, I mean pedantic sods like me?

As a general rule, and from my painful experience with C/C++ and the multitude of command line switches to change the language it will compile, I think it's best to avoid all compiler switches which change the language!
Jun 11 2002
parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
Fair enough.

Then let's have maximal pedantic built-in!

"Walter" <walter digitalmars.com> wrote in message
news:ae5man$7vv$1 digitaldaemon.com...
 "Matthew Wilson" <dm synesis-group.com> wrote in message
 news:ae3gtl$11dq$1 digitaldaemon.com...
 What do you think about having a compiler option "-pendantic" for
 practioners of the true way ... sorry, I mean pedantic sods like me?

As a general rule, and from my painful experience with C/C++ and the multitude of command line switches to change the language it will compile,

 think it's best to avoid all compiler switches which change the language!

Jun 11 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:ae5rej$djr$1 digitaldaemon.com...

 Fair enough.

 Then let's have maximal pedantic built-in!

Nooooo!!! =) Let's better have some way to move switches inside the programs, like VB's OPTION statement. int a; option strictbool = true; if (a) { ... } // error! option strictbool = false; if (a) { ... } // okay
Jun 12 2002
next sibling parent reply "Matthew Wilson" <dm synesis-group.com> writes:
Don't like it. I think a command-line option is better than this.

Never been a fan of having stuff in the code that pertains to environment /
user choices (such as #pragma comment(lib: etc. etc)

"Pavel Minayev" <evilone omen.ru> wrote in message
news:ae6voa$1ifk$1 digitaldaemon.com...
 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:ae5rej$djr$1 digitaldaemon.com...

 Fair enough.

 Then let's have maximal pedantic built-in!

Nooooo!!! =) Let's better have some way to move switches inside the programs, like VB's OPTION statement. int a; option strictbool = true; if (a) { ... } // error! option strictbool = false; if (a) { ... } // okay

Jun 12 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Matthew Wilson" <dm synesis-group.com> wrote in message
news:ae8hdb$1duq$1 digitaldaemon.com...

 Don't like it. I think a command-line option is better than this.

 Never been a fan of having stuff in the code that pertains to environment

 user choices (such as #pragma comment(lib: etc. etc)

But it is at least a _standard_ way of doing it, compatible across platforms, and partially eliminating the need for makefiles. Another programmer would just compile the program with a single call to dmd, and you don't have to write makefiles or bat-files..
Jun 13 2002
parent "Matthew Wilson" <matthew thedjournal.com> writes:
True

"Pavel Minayev" <evilone omen.ru> wrote in message
news:ae9hrv$2ica$1 digitaldaemon.com...
 "Matthew Wilson" <dm synesis-group.com> wrote in message
 news:ae8hdb$1duq$1 digitaldaemon.com...

 Don't like it. I think a command-line option is better than this.

 Never been a fan of having stuff in the code that pertains to


 /
 user choices (such as #pragma comment(lib: etc. etc)

But it is at least a _standard_ way of doing it, compatible across platforms, and partially eliminating the need for makefiles. Another programmer would just compile the program with a single call to dmd, and you don't have to write makefiles or bat-files..

Jun 13 2002
prev sibling parent "anderson" <anderson firestar.com.au> writes:
if there's going to be any option settings I like the openGL way.

glEnable/glDisable;

would be something lie

dEnable(D_STRICT_BOOL);
    if (a) { .... }
dDisable(D_STRICT_BOOL);

I treat them as a code block so I indent the middle. OpenGL also can
push/pop these values on the stack, but I thing that would probably would
give the complier a headake.

Or parhaps

dEnable (D_STRICT_BOOL)
{


}

But I'm talking in a general sense; if there were any optional things in d.
The d format should probably be worked out first though.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:ae6voa$1ifk$1 digitaldaemon.com...
 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:ae5rej$djr$1 digitaldaemon.com...

 Fair enough.

 Then let's have maximal pedantic built-in!

Nooooo!!! =) Let's better have some way to move switches inside the programs, like VB's OPTION statement. int a; option strictbool = true; if (a) { ... } // error! option strictbool = false; if (a) { ... } // okay

Jun 16 2002
prev sibling parent "J. Daniel Smith" <j_daniel_smith HoTMaiL.com> writes:
I think C# requires this: you have to write "if (v != null)" rather than "if
(v)".

Yes, being explicit is more typing, but it also seems to be one of those
guidelines that seems to make a frequent appearance on "coding standards"
documents.  The shorthand may be nice, but looking at "if (v)" in isolation,
you have know way of knowing if "v" is an integer, boolean or pointer which
can prompt people to use things like hungarian notation: "if (bV)", "if
(iV)", "if (pV)".  Without the shorthand, it's much clearer: in "if (v)", v
is boolean; in "if (v != 0)", v is an int, and in "if (v != null)" v is a
pointer.

   Dan

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:adum9g$23bh$1 digitaldaemon.com...
 null != 0 - I like that idea (though don't know why yet ...)

 type-safety - I like that very much. Very wise. Does this mean that
 conditional expressions involving pointers will have to be boolean, ie

 != null) rather than if(p) ?

 "Walter" <walter digitalmars.com> wrote in message
 news:aduk1j$216b$2 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:adu1ee$1fmj$1 digitaldaemon.com...
 Is there some reason why C++'s equivalence of NULL and 0 was



 not
 a good idea?  In porting C++ to D, I end up having to change a lot of


 to
 null.

 Just wondering if there's some reason for it or if it's just an


 It would sure be convenient.

The idea is that there are some cases where the null pointer might not


 0.
 I remember this issue from the early C days.

 The other idea is for type safety, i.e. making it clear you're dealing

 a null reference rather than a numerical 0.


Jun 10 2002
prev sibling next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:aduk1j$216b$2 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:adu1ee$1fmj$1 digitaldaemon.com...
 Is there some reason why C++'s equivalence of NULL and 0 was considered

 a good idea?  In porting C++ to D, I end up having to change a lot of


 to
 null.

 Just wondering if there's some reason for it or if it's just an


 It would sure be convenient.

The idea is that there are some cases where the null pointer might not be

 I remember this issue from the early C days.

The language can always insert extra code there to swap null handle values when comparing (how often do you compare resource handles anyway?) Can the concept of "resource handle" be baked into the language any better than it is now?
 The other idea is for type safety, i.e. making it clear you're dealing

 a null reference rather than a numerical 0.

I agree with your points. It's not a major issue... just a C++ porting issue then. ;( Unfortunately as someone who has written a lot of C++ code I'm pretty deeply entrenched in the language. I like null better than NULL anyhow since it is the same case as all the other object identifiers. hehe Sean
Jun 09 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:advb1o$2n7e$1 digitaldaemon.com...
 It's not a major issue... just a C++ porting issue then.  ;(

 as someone who has written a lot of C++ code I'm pretty deeply entrenched

 the language.

I've ported a lot of C++ code to D, I just do a global search/replace of NULL to null.
 I like null better than NULL anyhow since it is the same case as all the
 other object identifiers.  hehe

Yes, exactly. In C it is uppercase by the convention that macro constants are upper case.
Jun 09 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
But you can't global search/replace 0 with null.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:ae14em$1cvl$2 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:advb1o$2n7e$1 digitaldaemon.com...
 It's not a major issue... just a C++ porting issue then.  ;(

 as someone who has written a lot of C++ code I'm pretty deeply


 in
 the language.

I've ported a lot of C++ code to D, I just do a global search/replace of NULL to null.
 I like null better than NULL anyhow since it is the same case as all the
 other object identifiers.  hehe

Yes, exactly. In C it is uppercase by the convention that macro constants are upper case.

Jun 10 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ae2re0$8qk$1 digitaldaemon.com...
 But you can't global search/replace 0 with null.

True, but the compiler will quickly find them for you anyway <g>.
Jun 11 2002
parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Very true.  I use this to my advantage alot;  comment out or change the name
of a variable or function at point of declaration and poof the compiler
red-flags all occurrences of it.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:ae5man$7vv$2 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:ae2re0$8qk$1 digitaldaemon.com...
 But you can't global search/replace 0 with null.

True, but the compiler will quickly find them for you anyway <g>.

Jun 11 2002
prev sibling parent "J. Daniel Smith" <j_daniel_smith HoTMaiL.com> writes:
As I recall, the C FAQ goes into the NULL thing in quite a bit of detail.

The symbol 0 is overloaded in C: it means both the integer value zero and
the null pointer.  The compiler never (rarely?) has a problem distinguing
between the two, but humans reading the code get confused because 0 looks
the in the source code as a null pointer, thus the NULL macro for use in
pointer contexts.  To make things even more confusing, on the vast majority
of CPUs the bit string for the integer 0 and the null pointer are the same.

   Dan

"Walter" <walter digitalmars.com> wrote in message
news:aduk1j$216b$2 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:adu1ee$1fmj$1 digitaldaemon.com...
 Is there some reason why C++'s equivalence of NULL and 0 was considered

 a good idea?  In porting C++ to D, I end up having to change a lot of


 to
 null.

 Just wondering if there's some reason for it or if it's just an


 It would sure be convenient.

The idea is that there are some cases where the null pointer might not be

 I remember this issue from the early C days.

 The other idea is for type safety, i.e. making it clear you're dealing

 a null reference rather than a numerical 0.

Jun 10 2002