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

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

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

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.

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

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

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

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

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

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