if the following is build with Win32 DMD 0.43

import stream;

class OutputBuffer
{
public:
 this() { }
}

int main( char[][] args )
{
 try {
 OutputBuffer buf;

 printf("start:\n");
 if ( buf == null ) { buf = new OutputBuffer(); }

 printf("done:\n");

 } catch (Exception e ) {
  printf("Exception caught:\n");
  e.print();
 }
 return 0;
}

and then run, it just outputs the first line. 'start: ' then stiffs.
if you add a member function or two, (I had a couple and a char[][]
lines,member)
then you get the message 'Error: Out of memory'

if you comment out the   if ( buf == null ) line then it runs ( the =new
.... works )

Mike.

Mike Wynn wrote:
> if the following is build with Win32 DMD 0.43
> 
> import stream;
> 
> class OutputBuffer
> {
> public:
>  this() { }
> }
> 
> int main( char[][] args )
> {
>  try {
>  OutputBuffer buf;
> 
>  printf("start:\n");
>  if ( buf == null ) { buf = new OutputBuffer(); }

The "==" operator is transformed into "buf.eq (null)"; calling methods on null usually stalls.  The "===" operator is the one for comparing stack cells, or you may be able to do "!buf" (you definitely can on DLI, but DMD's a little clumsy when it comes to logic).

Burton Radons wrote:

> The "==" operator is transformed into "buf.eq (null)"; calling methods
> on null usually stalls.

Given that (as I understand it) buf is supposed to be null here, should we get a segfault?  Is the stall designed behavior or a bug to be fixed?

--
The Villagers are Online! http://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))) ]

arr, guess I should read the docs ...
I do find the === and !== operators a bit odd
with arrays == (2'='s) and (=== 3'='s) behave the same when checking against
null
(although new char[0] == null might be ok but new char[0] === null still
bugs me)

what type is null ? in Java arrays are objects and there are no pointers so null is an object

what does  if ( null == null )  { } do ? null.eq(null) or null === null ?
(FYI null==null and null===null are both true)

but in D null can be pointer, array or object
in D pointers and arrays are similar so I feel that null should be a
pointer/array type
and borrow the pascal/delphi/oberon 'nil' be used for the object 'null'
( obj == null ) would then cause a incompatable type compile time error
and (obj == nil ) would call obj.eq( nil ); and should cause the compiler to
issue a warning
(object value compared to nil at line ...)

This might help fools such as I, who write D code with a head full of C, C++, Java, Php and Perl syntax and make me thing about what I'm doing!


"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D99C541.2020701@users.sourceforge.net...
> Mike Wynn wrote:
> >  if ( buf == null ) { buf = new OutputBuffer(); }
>
> The "==" operator is transformed into "buf.eq (null)"; calling methods on null usually stalls.  The "===" operator is the one for comparing stack cells, or you may be able to do "!buf" (you definitely can on DLI, but DMD's a little clumsy when it comes to logic).
>

Mike Wynn wrote:
> arr, guess I should read the docs ...
> I do find the === and !== operators a bit odd
> with arrays == (2'='s) and (=== 3'='s) behave the same when checking against
> null
> (although new char[0] == null might be ok but new char[0] === null still
> bugs me)

I don't like it either; it's hard to remember to use it when it's practically indistinguishable from ==.  "is" would be handier.

> what type is null ? in Java arrays are objects and there are no pointers so
> null is an object

null takes its type from the expression context.

> what does  if ( null == null )  { } do ? null.eq(null) or null === null ?
> (FYI null==null and null===null are both true)

null assumes the type of (void *) when there's no context.  So it's just a pointer comparison.

> but in D null can be pointer, array or object
> in D pointers and arrays are similar so I feel that null should be a
> pointer/array type
> and borrow the pascal/delphi/oberon 'nil' be used for the object 'null'
> ( obj == null ) would then cause a incompatable type compile time error
> and (obj == nil ) would call obj.eq( nil ); and should cause the compiler to
> issue a warning
> (object value compared to nil at line ...)

Why?  It should definitely throw up if you try to call a method on a null object when debugging is on, but that's an easy thing to have, and it could be seen as invalid to compare objects against null.  Adding another keyword looks pointless.

> This might help fools such as I, who write D code with a head full of C,
> C++, Java, Php and Perl syntax and make me thing about what I'm doing!

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D99C541.2020701@users.sourceforge.net...
> Mike Wynn wrote:
> > if the following is build with Win32 DMD 0.43
> >
> > import stream;
> >
> > class OutputBuffer
> > {
> > public:
> >  this() { }
> > }
> >
> > int main( char[][] args )
> > {
> >  try {
> >  OutputBuffer buf;
> >
> >  printf("start:\n");
> >  if ( buf == null ) { buf = new OutputBuffer(); }
>
> The "==" operator is transformed into "buf.eq (null)"; calling methods on null usually stalls.  The "===" operator is the one for comparing stack cells...

Maybe the compiler could produce a warning (please) if explicit null is compared to an object with the original non-overloaded eq member from the Object class.

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:anea1p$c78$1@digitaldaemon.com...
> > The "==" operator is transformed into "buf.eq (null)"; calling methods on null usually stalls.  The "===" operator is the one for comparing stack cells...
> Maybe the compiler could produce a warning (please) if explicit null is compared to an object with the original non-overloaded eq member from the Object class.

You're right, I should investigate doing something about this. -Walter