www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 6 problems with DMD

reply Piotr Fusik <Piotr_member pathlink.com> writes:
Hello,

I have encountered the following problems with DMD 0.122:

1. DMD crashes after the error message
"function foo.bar (int) does not match argument types ()".

2. DMD crashes on "int x = 1 % 0;".

3. "debug:" does not work.
"debug {}" does.

4. Should I use "is" or "===" for comparing against null? Are they equivalent?

5. I think that the comparisons "== null" and "!= null" should be compile-time
errors.
Now they are run-time errors.

6. Why "array.length--" does not work?
"array.length = array.length - 1;" does.
May 17 2005
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
1. Already fixed in next release, regression in this release.

2. I think I read a bug report on that or similar... but, that should be 
in D.bugs.

3. Should it?  I don't see anything here that indicates it should:

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

And then how do you end the debug block?  Seems to me braces are better.

4. They are equivalent.  Some prefer is because it doesn't look like 
"==" to blind people or with bad fonts.

5. This has been discussed often, although it's theoretically possible 
for an initiated class to be equal to null (e.g. a string, if "", might be.)

6. Not sure on that one, although I know it was mentioned at least once.

-[Unknown]



 Hello,
 
 I have encountered the following problems with DMD 0.122:
 
 1. DMD crashes after the error message
 "function foo.bar (int) does not match argument types ()".
 
 2. DMD crashes on "int x = 1 % 0;".
 
 3. "debug:" does not work.
 "debug {}" does.
 
 4. Should I use "is" or "===" for comparing against null? Are they equivalent?
 
 5. I think that the comparisons "== null" and "!= null" should be compile-time
 errors.
 Now they are run-time errors.
 
 6. Why "array.length--" does not work?
 "array.length = array.length - 1;" does.
May 17 2005
parent reply Piotr Fusik <Piotr_member pathlink.com> writes:
 3. "debug:" does not work.
 "debug {}" does.
 


3. Should it?  I don't see anything here that indicates it should:

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


There's the following example:

class Foo
{
int a, b;
debug:
int flag;
}
May 17 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Piotr Fusik" <Piotr_member pathlink.com> wrote in message
news:d6cfq1$12fe$1 digitaldaemon.com...

 3. "debug:" does not work.
 "debug {}" does.


3. Should it?  I don't see anything here that indicates it should:

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


 There's the following example:

 class Foo
 {
 int a, b;
 debug:
 int flag;
 }


/* Not sure why you used the colon character after the "debug" keyword.
Try removing it.
The following code compiles... */

void main()
{
int a, b;
debug int flag;
}

// TZ
May 18 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 17 May 2005 07:49:35 +0000 (UTC), Piotr Fusik wrote:


 Hello,
 
 I have encountered the following problems with DMD 0.122:
 
 1. DMD crashes after the error message
 "function foo.bar (int) does not match argument types ()".


This has been fixed in v0.123


 2. DMD crashes on "int x = 1 % 0;".


 
Don't know about this one.


 3. "debug:" does not work.
 "debug {}" does.


This is a mistake in the documentation. The example should read ...

  class Foo  
  {
      int a, b;
      debug int flag;
  }   


 4. Should I use "is" or "===" for comparing against null? Are they equivalent?


They are the same thing. The preferred usage is "is". Don't use "===" as it
is sometimes harder to read.
 

 5. I think that the comparisons "== null" and "!= null" should be compile-time
 errors.
 Now they are run-time errors.


How can they be compile-time errors?

  void Func( Foo a)
  {
      if (a == null)
         . . .
  }

This can only be determined at run time, because sometimes it is not an
error. There could be an opEqual member defined for the Foo class.



 6. Why "array.length--" does not work?
 "array.length = array.length - 1;" does.


Because 'length' is not a member variable of an array. It is more like a
property function. It is as if you had a class called array and it has a
property function called length...

   class array
   {
      uint length() { return ... }
      void length(uint newvalue) { . . . }
   }

so that when you type 

   array.length++;

its is like you typed ...

   array.length()++;

and that is not possible as a function call is not an lvalue.

  array.length = array.length + 1;

is like typing ...

   array.length( array.length() + 1);

-- 
Derek Parnell
Melbourne, Australia
17/05/2005 9:17:39 PM
May 17 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 5. I think that the comparisons "== null" and "!= null" should be 
 compile-time
 errors.
 Now they are run-time errors.


 How can they be compile-time errors?

  void Func( Foo a)
  {
      if (a == null)
         . . .
  }

 This can only be determined at run time, because sometimes it is not an
 error. There could be an opEqual member defined for the Foo class.


The problem with "a == null" comes when "a is null" since calling opEquals 
causes a null-pointer dereference (it never even makes it to the opEquals 
body). A compile-time error is pretty harsh though I sympathize because it 
is pretty obviously a coder error. I want to add a check for this to dlint 
but I haven't gotten around to it.
May 17 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d6cnp1$195o$1 digitaldaemon.com...

 5. I think that the comparisons "== null" and "!= null" should be
 compile-time
 errors.
 Now they are run-time errors.


 How can they be compile-time errors?

  void Func( Foo a)
  {
      if (a == null)
         . . .
  }

 This can only be determined at run time, because sometimes it is not an
 error. There could be an opEqual member defined for the Foo class.


 The problem with "a == null" comes when "a is null" since calling opEquals
 causes a null-pointer dereference (it never even makes it to the opEquals
 body). A compile-time error is pretty harsh though I sympathize because it
 is pretty obviously a coder error. I want to add a check for this to dlint
 but I haven't gotten around to it.


The solution to that would be to treat null.opEquals as a predefined member
function of null, when it's requested.
In other words, the compiler could be made to compensate for the problem by
attaching a default behavior to the requested action at compile-time.

TZ
May 18 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:nfamciwrwl02.1vztstuf0ghzv$.dlg 40tude.net...

 On Tue, 17 May 2005 07:49:35 +0000 (UTC), Piotr Fusik wrote:


*snip*

 3. "debug:" does not work.
 "debug {}" does.


 This is a mistake in the documentation. The example should read ...

   class Foo
   {
       int a, b;
       debug int flag;
   }


*snip*

 -- 
 Derek Parnell
 Melbourne, Australia
 17/05/2005 9:17:39 PM


Oops... I should have read ahead before saying basically the same thing you had
already said.  Hehe.

TZ
May 18 2005