Fleshed out operator overloading support.

ftp://ftp.digitalmars.com/dmdalpha.zip

Digital Mars D Compiler ALPHA v0.38

The following code causes:
Internal error: ..\ztc\cgcod.c 1402

struct RECT
{
    int    left;
    int    top;
    int    right;
    int    bottom;
}

struct Rect
{
  RECT theRect;
}


void Test(Rect pos)
{
}

class Window
{
  protected Rect position;

  public void createWindow()
  {
    Test(position);
  }
}

Ok, I'll check it out. Thanks. -Walter

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns9272ECBFBBFDFpatcodemooncom@63.105.9.61...
> Digital Mars D Compiler ALPHA v0.38
>
> The following code causes:
> Internal error: ..\ztc\cgcod.c 1402
>
> struct RECT
> {
>     int    left;
>     int    top;
>     int    right;
>     int    bottom;
> }
>
> struct Rect
> {
>   RECT theRect;
> }
>
>
> void Test(Rect pos)
> {
> }
>
> class Window
> {
>   protected Rect position;
>
>   public void createWindow()
>   {
>     Test(position);
>   }
> }

"Walter" <walter@digitalmars.com> wrote in news:ak20qg$2v22$1 @digitaldaemon.com:

> Fleshed out operator overloading support.
> 
> ftp://ftp.digitalmars.com/dmdalpha.zip

The following causes:
Internal error: e2ir.c 1726

import importme;

int main(char[][] argv)
{
  if(importme)
  {
  }

  return 1;
}

This variant crashes the compiler hard.
I found these when I made a stupid mistake
and named a variable the same as a import module.

import importme;

int main(char[][] argv)
{
  int a;
  if(a == 0 && importme)
  {
  }

  return 1;
}

Comiple and run the following and get:
Error: ArrayBoundsError string(188)

import string;

int main(char[][] argv)
{
  char[] test = "";

  toStringz(test);

  return 1;
}

On Sun, 25 Aug 2002 03:01:22 +0000 (UTC) Patrick Down <pat@codemoon.com> wrote:

> import importme;
> 
> int main(char[][] argv)
> {
>   if(importme)
>   {
>   }
> 
>   return 1;
> }

I think this bug was there ever since the first version I've saw. The compiler
tends to crash when things are used where they are not supposed to be
used - try assigning to a function name, for example =)

"Walter" <walter@digitalmars.com> wrote in message news:ak20qg$2v22$1@digitaldaemon.com...
> Fleshed out operator overloading support.
>
> ftp://ftp.digitalmars.com/dmdalpha.zip

Quoting operatoroverloading.html:

------------------------
Both operators use the eq() function. The expression (a == b) is rewritten
as a.equals(b), and (a != b) is rewritten as !a.equals(b).
The member function eq() is defined as part of Object as:

	int eq(Object o);

so that every class object has an eq().
If a struct has no eq() function declared for it, a bit compare of the
contents of the two structs is done to determine equality or inequality.

------------------------
1) Is it a.equals(b) or a.eq(b)?

2) About bit comparing structs: Isn't there some problem with trash inside alignment being different for two structs?

3) There should be some way to catch comparsions between uncomparable types
at compile time. Maybe the compiler can warn for calling functions with
assert(0) as their first line? (see end of operatoroverloading.html)

Yours,
Sandor

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:akd1b7$1do9$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:ak20qg$2v22$1@digitaldaemon.com...
> > Fleshed out operator overloading support.
> >
> > ftp://ftp.digitalmars.com/dmdalpha.zip
>
> Quoting operatoroverloading.html:
>
> ------------------------
> Both operators use the eq() function. The expression (a == b) is rewritten
> as a.equals(b), and (a != b) is rewritten as !a.equals(b).
> The member function eq() is defined as part of Object as:
>
> int eq(Object o);
>
> so that every class object has an eq().
> If a struct has no eq() function declared for it, a bit compare of the
> contents of the two structs is done to determine equality or inequality.
>
> ------------------------
> 1) Is it a.equals(b) or a.eq(b)?

eq(), I'll fix the doc!

> 2) About bit comparing structs: Isn't there some problem with trash inside alignment being different for two structs?

In C/C++ there is. In D, the gaps are guaranteed to be set to 0.

> 3) There should be some way to catch comparsions between uncomparable
types
> at compile time. Maybe the compiler can warn for calling functions with
> assert(0) as their first line? (see end of operatoroverloading.html)

I think that's a quality-of-implementation issue.