www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - What's the replacement for this array initialization: "ubyte[4096]

reply Marco Leise <Marco.Leise gmx.de> writes:
  struct ExpandData
  {
    /// Last seen bytes during expansion.
    ubyte[4096] window = 0;
    ...
  }


I noticed in 2.062 this code doesn't work anymore. The
compiler still does the initial type conversion of 0 from int
to ubyte, but the assignment fails with:

  cannot implicitly convert expression (cast(ubyte)0u) of type
  ubyte to ubyte[4096LU]

So I'm wondering to do this now. I want to be explicit so a
reader knows I explicitly set the initial value of this array
in that structure to all zeros. My argument is that D
initializes not with the most convenient, but the most wrong
value in order to provoke reproducible errors. So in general
you should initialize to sane values.

-- 
Marco
Feb 21 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 02/21/2013 08:10 PM, Marco Leise wrote:
    struct ExpandData
    {
      /// Last seen bytes during expansion.
      ubyte[4096] window = 0;
      ...
    }


 I noticed in 2.062 this code doesn't work anymore. The
 compiler still does the initial type conversion of 0 from int
 to ubyte, but the assignment fails with:

    cannot implicitly convert expression (cast(ubyte)0u) of type
    ubyte to ubyte[4096LU]
There must be something else. The same code compiles with the released dmd 2.062 here. Are you using the latest dmd at github? Ali
Feb 21 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 21 Feb 2013 20:26:56 -0800
schrieb Ali =C3=87ehreli <acehreli yahoo.com>:

 On 02/21/2013 08:10 PM, Marco Leise wrote:
  >    struct ExpandData
  >    {
  >      /// Last seen bytes during expansion.
  >      ubyte[4096] window =3D 0;
  >      ...
  >    }
  >
  >
  > I noticed in 2.062 this code doesn't work anymore. The
  > compiler still does the initial type conversion of 0 from int
  > to ubyte, but the assignment fails with:
  >
  >    cannot implicitly convert expression (cast(ubyte)0u) of type
  >    ubyte to ubyte[4096LU]
=20
 There must be something else. The same code compiles with the released=20
 dmd 2.062 here. Are you using the latest dmd at github?
=20
 Ali
You are right, it compiles in isolated cases. By the looks of the error message I didn't imagine it would depend on any surrounding code. So it is a regression of unknown source :) --=20 Marco
Feb 21 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
This is now: http://d.puremagic.com/issues/show_bug.cgi?id=9566

-- 
Marco
Feb 21 2013
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 22 February 2013 at 04:10:52 UTC, Marco Leise wrote:
 So I'm wondering to do this now. I want to be explicit so a
 reader knows I explicitly set the initial value of this array
 in that structure to all zeros. My argument is that D
 initializes not with the most convenient, but the most wrong
 value in order to provoke reproducible errors. So in general
 you should initialize to sane values.
That's not entirely true. For integers, the initialization is always 0, which is expected and convenient. For characters, it's 0xFF, because what else are you going to initialize it to? space? Given there is no standard default initial value, D chose the mostest garbage value possible (but in a defined behavior). As for floats, well, arguably, I prefer the NaN behavior, because floats are very strange beasts, and the initialization scheme reminds me that there are many many many pitfals to remember.
Feb 21 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 22 Feb 2013 08:02:14 +0100
schrieb "monarch_dodra" <monarchdodra gmail.com>:

 That's not entirely true. For integers, the initialization is 
 always 0, which is expected and convenient.
Yes, luckily for us integers didn't have a wrong/garbage value like floats and UTF-8 chars. But the design intent was to provoke errors on uninitialized variables, so I try to make that principle mine and initialize even integers to 0 explicitly. -- Marco
Feb 22 2013