• Sean L. Palmer (6/6) Jun 08 2002 Is there some reason why C++'s equivalence of NULL and 0 was considered ...
• Matthew Wilson (9/15) Jun 08 2002 It could be that it is much better for maintenance.
• Sean L. Palmer (11/30) Jun 08 2002 I don't know what maintenance programmers have against using browse info...
• Matthew Wilson (13/54) Jun 08 2002 What if you're using browse info? What if (as is common) you're reading ...
• Walter (8/13) Jun 08 2002 not
• Matthew Wilson (10/24) Jun 08 2002 null != 0 - I like that idea (though don't know why yet ...)
• Sean L. Palmer (7/34) Jun 09 2002 That's the thing... it's a lot more typing. Three more characters. he...
• Walter (4/7) Jun 09 2002 if(p
• Russ Lewis (13/20) Jun 10 2002
• Pavel Minayev (3/7) Jun 10 2002 It is already forbidden in D!
• Russ Lewis (16/23) Jun 11 2002 Two questions:
• Pavel Minayev (9/19) Jun 11 2002 It isn't in the docs anywhere. Walter mentioned it in the newsgroup twic...
• Russ Lewis (13/32) Jun 11 2002 I'm awfully close to a Bison parser that can parse D (it seems as though...
• C.R.Chafer (8/16) Jun 12 2002 Me too.
• Pavel Minayev (7/11) Jun 12 2002 it
• Russ Lewis (7/18) Jun 12 2002 Yeah, but it gets really ugly.
• Walter (5/15) Jun 11 2002 This is not in the parser. It is in the semantic analysis phase, where
• Pavel Minayev (3/8) Jun 10 2002 Oh yes! Please PLEASE PLEASE keep it! =)
• Matthew Wilson (4/11) Jun 10 2002 What do you think about having a compiler option "-pendantic" for
• Walter (5/7) Jun 11 2002 As a general rule, and from my painful experience with C/C++ and the
• Matthew Wilson (5/12) Jun 11 2002 Fair enough.
• Pavel Minayev (10/12) Jun 12 2002 Nooooo!!! =)
• Matthew Wilson (5/18) Jun 12 2002 Don't like it. I think a command-line option is better than this.
• Pavel Minayev (8/11) Jun 13 2002 /
• Matthew Wilson (4/16) Jun 13 2002 True
• anderson (17/30) Jun 16 2002 if there's going to be any option settings I like the openGL way.
• J. Daniel Smith (16/45) Jun 10 2002 I think C# requires this: you have to write "if (v != null)" rather than...
• Sean L. Palmer (17/31) Jun 09 2002 0's
• Walter (8/13) Jun 09 2002 Unfortunately
• Sean L. Palmer (5/18) Jun 10 2002 But you can't global search/replace 0 with null.
• Walter (3/4) Jun 11 2002 True, but the compiler will quickly find them for you anyway .
• Sean L. Palmer (6/10) Jun 11 2002 Very true. I use this to my advantage alot; comment out or change the ...
• J. Daniel Smith (14/28) Jun 10 2002 As I recall, the C FAQ goes into the NULL thing in quite a bit of detail...

"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

"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

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

"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

 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

"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

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

"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

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.

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.

"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

 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.

 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.

"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

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

 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.

"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

if(p
 != null) rather than if(p) ?

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

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

 if(p
 != 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))) ]

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

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

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

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

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

"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

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.

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

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

 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.

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

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

"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

 if(p
 != 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! =)

"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

 if(p
 != null) rather than if(p) ?

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

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

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

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

"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

"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

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

"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


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

"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

"J. Daniel Smith" <j_daniel_smith HoTMaiL.com> writes:

(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

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

 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.

"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

 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.

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

with
 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

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

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

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.

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

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


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

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

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

"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

 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.

 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.