DMD 0.59.  This code prints 0 when I expect 4:

    real x = 4;
    long y;

    void main ()
    {
        y = x;
        printf ("%Ld\n", y);
    }

Changing the assignment to "y = (double) x;" amends the problem.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b5bi8e$s6d$1@digitaldaemon.com...
> DMD 0.59.  This code prints 0 when I expect 4:
>      real x = 4;
>      long y;
>
>      void main ()
>      {
>          y = x;
>          printf ("%Ld\n", y);
>      }
> Changing the assignment to "y = (double) x;" amends the problem.

To print D longs, use the %lld format. (D longs are equivalent to C++ long
longs.)

Walter wrote:
> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:b5bi8e$s6d$1@digitaldaemon.com...
> 
>>DMD 0.59.  This code prints 0 when I expect 4:
>>     real x = 4;
>>     long y;
>>
>>     void main ()
>>     {
>>         y = x;
>>         printf ("%Ld\n", y);
>>     }
>>Changing the assignment to "y = (double) x;" amends the problem.
> 
> 
> To print D longs, use the %lld format. (D longs are equivalent to C++ long
> longs.)

It's not casting properly regardless.

DMD 0.59.  This code improperly fails compilation with "f.d(7): cannot implicitly convert int to foo":

  typedef int foo;

  foo [foo] list;

  void main ()
  {
      foo x = list.keys [(foo) 0]; // This line fails.
  }

It appears that list.keys is int[] and not foo[] as it should be.

DMD 0.59.  I'm getting the "circular initialization dependency with module diggl" error really bad - it's never spawned correctly, and if it were correctly spawned there would be no way to detect when I address the problem by making init functions.  So I have to put some initialisation in the wrong file, which can lead to mysterious errors when the part of the library which has the initialiser isn't included in an executable but the part the initialiser is for is.  For example, I have this in digcanvasgl.d:

  static this ()
  {
      ...
      gl = new GL;
  }

GL is in diggl.d, and it only depends upon digcanvasgl for some member fields, so using diggl doesn't necessarily include digcanvasgl in the executable.  El presto, initialiser isn't called, and code which is in this class will fail completely mysteriously.  I don't like having to write incorrect code just to get a compiler to shut up.

To get rid of the error, two modules which import each other, one of them has to not have any static initializers.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b5j4tr$boi$1@digitaldaemon.com...
> DMD 0.59.  I'm getting the "circular initialization dependency with module diggl" error really bad - it's never spawned correctly, and if it were correctly spawned there would be no way to detect when I address the problem by making init functions.  So I have to put some initialisation in the wrong file, which can lead to mysterious errors when the part of the library which has the initialiser isn't included in an executable but the part the initialiser is for is.  For example, I have this in digcanvasgl.d:
>
>    static this ()
>    {
>        ...
>        gl = new GL;
>    }
>
> GL is in diggl.d, and it only depends upon digcanvasgl for some member fields, so using diggl doesn't necessarily include digcanvasgl in the executable.  El presto, initialiser isn't called, and code which is in this class will fail completely mysteriously.  I don't like having to write incorrect code just to get a compiler to shut up.
>