www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - prediction: most common (and cursed) D pitfalls

reply d c++.com writes:
I'd like to make a prediction: the most common D pitfalls for people coming from
C/C++/Java will be:

========================================
SomeClass obj = someFunc();

if (obj!=null) {  // core dump here! when obj is actually null
obj.doSomething()
}
========================================

This is such a common idiom in C/C++/Java that when you get a pointer/reference
as a return value, you may want to check if it's null/NULL before making method
call on it.

I simply don't understand why D change the semantics of "!=" and "==" from
Java/C++/C, and re-invent such strange things like "==="/"is" to act as identity
testing; On the other hand, D is trying hard to attact people from Java/C++
camp.

I agree that we need two kinds of operators: one for identity, one for equality.
And testing for identity with null (obj==null) is much more common than testing
for equality (a.equals(b)) in real code.  So why not just follow the established
convention? and why change such trivial things to incur such great danger as
segfaults, and annoying your potential user?

I will further predict that this will be the most cursed language (mis)feature
when D become popular.  I for one curse it from now on!
Apr 29 2005
next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
some relevant threads:
http://www.digitalmars.com/d/archives/18188.html
http://www.digitalmars.com/d/archives/digitalmars/D/8580.html
http://www.digitalmars.com/d/archives/16851.html
http://www.digitalmars.com/d/archives/12144.html
http://www.digitalmars.com/d/archives/8726.html
and probably more...

<d c++.com> wrote in message news:d4tvuo$1egr$1 digitaldaemon.com...

 I'd like to make a prediction: the most common D pitfalls for people 
 coming from
 C/C++/Java will be:

 ========================================
 SomeClass obj = someFunc();

 if (obj!=null) {  // core dump here! when obj is actually null
 obj.doSomething()
 }
 ========================================

 This is such a common idiom in C/C++/Java that when you get a 
 pointer/reference
 as a return value, you may want to check if it's null/NULL before making 
 method
 call on it.

 I simply don't understand why D change the semantics of "!=" and "==" from
 Java/C++/C, and re-invent such strange things like "==="/"is" to act as 
 identity
 testing; On the other hand, D is trying hard to attact people from 
 Java/C++
 camp.

 I agree that we need two kinds of operators: one for identity, one for 
 equality.
 And testing for identity with null (obj==null) is much more common than 
 testing
 for equality (a.equals(b)) in real code.  So why not just follow the 
 established
 convention? and why change such trivial things to incur such great danger 
 as
 segfaults, and annoying your potential user?

 I will further predict that this will be the most cursed language 
 (mis)feature
 when D become popular.  I for one curse it from now on!
Apr 29 2005
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 29 Apr 2005 18:55:20 +0000 (UTC), d c++.com wrote:


 I'd like to make a prediction: the most common D pitfalls for people coming
from
 C/C++/Java will be:
 
 ========================================
 SomeClass obj = someFunc();
 
 if (obj!=null) {  // core dump here! when obj is actually null
 obj.doSomething()
 }
 ========================================
 
 This is such a common idiom in C/C++/Java that when you get a pointer/reference
 as a return value, you may want to check if it's null/NULL before making method
 call on it.


You may be right; I don't really know about that. However, as a person
*not* coming from a C++/Java background, I have not found anything (read:
"not one single thing") problematic about this. It, in fact, seems natural
to me. I always use '==' to test for equality, and 'is' to test for
identity. 

I tell a lie, there is one unreasonable restriction with 'is'. 

class Foo {};

Foo af = new Foo;
Foo bf = new Foo;

int ai;
int bi;

char[] aa;
char[] ba;

if (af is bf) ... // ok
if (ai is bi) ... // ok
if (aa is bb) ... // ok
if (af is bi) ... // fails
if (af is aa) ... // fails
if (ai is aa) ... // fails

So what's so about wrong with trying to test the identity of native types
with classes or arrays? This makes template writing a PITA.

-- 
Derek Parnell
Melbourne, Australia
30/04/2005 9:53:11 AM
Apr 29 2005
prev sibling next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
d c++.com wrote:

 I'd like to make a prediction: the most common D pitfalls for people coming
from
 C/C++/Java will be:
 
 ========================================
 SomeClass obj = someFunc();
 
 if (obj!=null) {  // core dump here! when obj is actually null
 obj.doSomething()
 }
 ========================================
 
 This is such a common idiom in C/C++/Java that when you get a pointer/reference
 as a return value, you may want to check if it's null/NULL before making method
 call on it.
 
 I simply don't understand why D change the semantics of "!=" and "==" from
 Java/C++/C, and re-invent such strange things like "==="/"is" to act as
identity
 testing; On the other hand, D is trying hard to attact people from Java/C++
 camp.
 
 I agree that we need two kinds of operators: one for identity, one for
equality.
 And testing for identity with null (obj==null) is much more common than testing
 for equality (a.equals(b)) in real code.  So why not just follow the
established
 convention? and why change such trivial things to incur such great danger as
 segfaults, and annoying your potential user?
 
 I will further predict that this will be the most cursed language (mis)feature
 when D become popular.  I for one curse it from now on!
 
 


I come from a C++/Java background, and have never had a problem with it. 
It's explained in the docs quite clearly, so I don't see what the 
problem is.
May 01 2005
prev sibling parent zwang <nehzgnaw gmail.com> writes:
Isn't it a common idiom to use the more succinct form "if(obj)doSomething();"
in C/C++?


d c++.com wrote:

 I'd like to make a prediction: the most common D pitfalls for people coming
from
 C/C++/Java will be:
 
 ========================================
 SomeClass obj = someFunc();
 
 if (obj!=null) {  // core dump here! when obj is actually null
 obj.doSomething()
 }
 ========================================
 
 This is such a common idiom in C/C++/Java that when you get a pointer/reference
 as a return value, you may want to check if it's null/NULL before making method
 call on it.
 
 I simply don't understand why D change the semantics of "!=" and "==" from
 Java/C++/C, and re-invent such strange things like "==="/"is" to act as
identity
 testing; On the other hand, D is trying hard to attact people from Java/C++
 camp.
 
 I agree that we need two kinds of operators: one for identity, one for
equality.
 And testing for identity with null (obj==null) is much more common than testing
 for equality (a.equals(b)) in real code.  So why not just follow the
established
 convention? and why change such trivial things to incur such great danger as
 segfaults, and annoying your potential user?
 
 I will further predict that this will be the most cursed language (mis)feature
 when D become popular.  I for one curse it from now on!
May 01 2005