digitalmars.D.learn - What's the replacement for this array initialization: "ubyte[4096]
- Marco Leise (19/19) Feb 21 2013 struct ExpandData
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (4/15) Feb 21 2013 There must be something else. The same code compiles with the released
- Marco Leise (7/27) Feb 21 2013 You are right, it compiles in isolated cases. By the looks of
- Marco Leise (3/3) Feb 21 2013 This is now: http://d.puremagic.com/issues/show_bug.cgi?id=9566
- monarch_dodra (10/16) Feb 21 2013 That's not entirely true. For integers, the initialization is
- Marco Leise (9/11) Feb 22 2013 Yes, luckily for us integers didn't have a wrong/garbage value
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
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
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 AliYou 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
This is now: http://d.puremagic.com/issues/show_bug.cgi?id=9566 -- Marco
Feb 21 2013
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
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