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

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

bobef wrote:
> if(obj==null) {...}
== is a member function.
Calling member functions on uninitialised objects is currently not supported.

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?

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.

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.

/opt/gdc/include/d/std/format.d#342:
>                 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

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.