www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - can't compare uninitialized objects to null?

reply bobef <bobef_member pathlink.com> writes:
If I have

myclass obj; //wthout =new myclass;
if(obj==null) {...}

I get a program crash.
If I write it down as

myclass obj;
if(obj) {...} //or if(!obj)

everythin is ok. Is that normal?
I spent an hour pressing  "don't send" to find this was the problem :)
Jan 30 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
bobef wrote:


 If I have
 myclass obj; //wthout =new myclass;
 if(obj==null) {...}
 
 I get a program crash.


You need to use "if (obj is null)"


 If I write it down as
 
 myclass obj;
 if(obj) {...} //or if(!obj)
 
 everythin is ok. Is that normal?


Yes.

--anders
Jan 30 2005
prev sibling parent reply Benjamin Herr <ben 0x539.de> writes:
bobef wrote:

 if(obj==null) {...}


== is a member function.
Calling member functions on uninitialised objects is currently not 
supported.
Jan 30 2005
next sibling parent reply Daniel Horn <hellcatv hotmail.com> writes:
Benjamin Herr wrote:

 bobef wrote:
 

 if(obj==null) {...}


 
 == is a member function.
 Calling member functions on uninitialised objects is currently not 
 supported.


that particular expression or null==obj could easily be detected at 
compile time :-)
nothing fancy...just the literal null being compared to obj.
That would return a compiler error "null being compared with == instead 
of is" and would help hundreds of newbies get a pleasant first 
impression of D.

Walter?
Jan 31 2005
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Daniel Horn wrote:


 Benjamin Herr wrote:

 bobef wrote:
 

 if(obj==null) {...}


 
 == is a member function.
 Calling member functions on uninitialised objects is currently not
 supported.


 that particular expression or null==obj could easily be detected at
 compile time :-)
 nothing fancy...just the literal null being compared to obj.
 That would return a compiler error "null being compared with == instead
 of is" and would help hundreds of newbies get a pleasant first
 impression of D.


This has just recently been discussed in this group.

Making it a compiler error would require to change the language where it
would be a rather awkward special rule. (Why should one not be allowed to
compare objects to null? 'obj == null' just translates into
'obj.obEquals(null)' - why should you not be allowed to call this function
with 'null' as argument?)

What could be done and might be very helpful to newbies is a compiler
warning. So far, Walter is still reluctant to include warnings into the
compiler, but as long as nobody has an idea for a real solution, I think it
is better to have the compiler say something than to be quiet about it and
let every newby struggle the same fight.
Jan 31 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Norbert Nemec wrote:


that particular expression or null==obj could easily be detected
 


 This has just recently been discussed in this group.
 
 Making it a compiler error would require to change the language where it
 would be a rather awkward special rule. (Why should one not be allowed to
 compare objects to null? 'obj == null' just translates into
 'obj.obEquals(null)' - why should you not be allowed to call this function
 with 'null' as argument?)


1) Because it's never what you want, unless obj is a pointer...
2) Because the compiler already acts maternal when it sees '=' ?

iftest.d:

 void main()
 {
   Object n = null;
   if (n = null) { }
 }


iftest.d:4: '=' does not give a boolean result

eqtest.d:

 void main()
 {
   Object n = null;
   if (n == null) { }
 }


("go ahead and call null.opEquals(null), see if care")


I think the second is enough to warrant a similar compiler error,
even if it doesn't really "crash", but "just" dereferences null...


 Program received signal EXC_BAD_ACCESS, Could not access memory.
 0x00002530 in _Dmain () at eqtest.d:5
 5         if (n == null) { }


You are even supposed to get an Exception, but that only
works on Windows so far - not on Linux, or Darwin with GDC.


I think it's a part of D's design, to "fail hard" on wrong input ?
(as the DBC contracts are supposed to verify such faulty parameters)

Such as:


 import std.stdio;
 void main()
 {
   Object n = null;
   writefln("%s",n);
 }


Gives:


 Program received signal EXC_BAD_ACCESS, Could not access memory.
 _D3std6format8doFormat9formatArgFaZv (fc=115 's') at
../gcc/d/phobos/std/format.d:342
 342     ../gcc/d/phobos/std/format.d: No such file or directory.




                 s = vobject.toString();



Without the debugger, they both just "bus error" (a.k.a segfault/A.V.)

Both C and Java print something like "(null)" for this second example.
At least on this machine, it's possible they segfault or print nothing.



 What could be done and might be very helpful to newbies is a compiler
 warning. So far, Walter is still reluctant to include warnings into the
 compiler, but as long as nobody has an idea for a real solution, I think it
 is better to have the compiler say something than to be quiet about it and
 let every newby struggle the same fight.


Walter has said that the compiler will not ever get warnings.
Either it's an error, or it is allowed. (compare -Werr in GCC)

http://www.digitalmars.com/d/overview.html:

 No Warnings

 D compilers will not generate warnings for questionable code. Code will
 either be acceptable to the compiler or it will not be. This will
 eliminate any debate about which warnings are valid errors and which are
 not, and any debate about what to do with them. The need for compiler
 warnings is symptomatic of poor language design.


But it could be an error ?

--anders
Jan 31 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Benjamin Herr wrote:

 bobef wrote:
 

 if(obj==null) {...}


 
 == is a member function.
 Calling member functions on uninitialised objects is currently not 
 supported.


I doubt it ever will, as dereferencing a null pointer in order to find 
the pointer to vtbl just isn't going to work.

Maybe it can work on functions that end up optimised to be non-virtual. 
   But it would be silly to try and rely on this.  And struct members, 
considering that structs don't have inheritance.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 31 2005