• "Sean L. Palmer" <seanpalmer earthlink.net> Jun 08 2002
• "Matthew Wilson" <dmd synesis.com.au> Jun 08 2002
• "Sean L. Palmer" <seanpalmer earthlink.net> Jun 08 2002
• "Matthew Wilson" <dmd synesis.com.au> Jun 08 2002
• "Walter" <walter digitalmars.com> Jun 08 2002
• "Matthew Wilson" <dmd synesis.com.au> Jun 08 2002
• "Sean L. Palmer" <seanpalmer earthlink.net> Jun 09 2002
• "Walter" <walter digitalmars.com> Jun 09 2002
• Russ Lewis <spamhole-2001-07-16 deming-os.org> Jun 10 2002
• "Pavel Minayev" <evilone omen.ru> Jun 10 2002
• Russ Lewis <spamhole-2001-07-16 deming-os.org> Jun 11 2002
• "Pavel Minayev" <evilone omen.ru> Jun 11 2002
• Russ Lewis <spamhole-2001-07-16 deming-os.org> Jun 11 2002
• C.R.Chafer <blackmarlin nospam.asean-mail.com> Jun 12 2002
• "Pavel Minayev" <evilone omen.ru> Jun 12 2002
• Russ Lewis <spamhole-2001-07-16 deming-os.org> Jun 12 2002
• "Walter" <walter digitalmars.com> Jun 11 2002
• "Pavel Minayev" <evilone omen.ru> Jun 10 2002
• "Matthew Wilson" <dm synesis-group.com> Jun 10 2002
• "Walter" <walter digitalmars.com> Jun 11 2002
• "Matthew Wilson" <dmd synesis.com.au> Jun 11 2002
• "Pavel Minayev" <evilone omen.ru> Jun 12 2002
• "Matthew Wilson" <dm synesis-group.com> Jun 12 2002
• "Pavel Minayev" <evilone omen.ru> Jun 13 2002
• "Matthew Wilson" <matthew thedjournal.com> Jun 13 2002
• "anderson" <anderson firestar.com.au> Jun 16 2002
• "J. Daniel Smith" <j_daniel_smith HoTMaiL.com> Jun 10 2002
• "Sean L. Palmer" <seanpalmer earthlink.net> Jun 09 2002
• "Walter" <walter digitalmars.com> Jun 09 2002
• "Sean L. Palmer" <seanpalmer earthlink.net> Jun 10 2002
• "Walter" <walter digitalmars.com> Jun 11 2002
• "Sean L. Palmer" <seanpalmer earthlink.net> Jun 11 2002
• "J. Daniel Smith" <j_daniel_smith HoTMaiL.com> Jun 10 2002

"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


 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

"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

"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

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

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

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

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

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

"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


 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?

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

"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


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


 != 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,


 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




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

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.

"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

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

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

"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


 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.