www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Array void init

reply =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
Should this be supported?

     double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];

(it's not supported at the moment)
Apr 26 2013
next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
Just to clarify, this is supported, of course:

      double[8] foo = void;
      foo[0] = 1.0;
      foo[1] = 2.0;
      foo[3] = 3.0;
      foo[4] = 3.5;
Apr 26 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Luís Marques:

 Should this be supported?

     double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, 
 void];

 (it's not supported at the moment)

I think I have not needed this so far. It looks dangerous. Generally D tries to initialize variables. What are your use cases? Bye, bearophile
Apr 26 2013
prev sibling next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
Hi bearophile.

This was just an academic question. It just seemed to me that if 
"double[8] foo = void" was deemed to warrant support, that it is 
a bit unorthogonal not to support the void in the specific 
indexes. This is just nitpicking, but I thought it might be worth 
asking, it could be that support for this was just an oversight 
or DMD limitation.
Apr 26 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 26 April 2013 at 14:58:35 UTC, Luís Marques wrote:
 Should this be supported?

     double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, 
 void];

 (it's not supported at the moment)

which reminds me about the proposal to allow declaration of static arrays with double[$] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void]; which is more convenient since one discovers a counting error only when compiles. Has a decision been reached for this issue? Currently in gdc: double[$] foo = [1.0, 2.0]; fails with main.d:18: Error: undefined identifier __dollar double[1] foo = [1.0, 2.0]; fails with main.d:18: Error: array initializer has 2 elements, but array length is 1 but double[4] foo = [1.0, 2.0]; is accepted, which is a bit strange (I think the compiler should give at least a warning if too many elements are reserved for an array).
Apr 26 2013
prev sibling next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
On Friday, 26 April 2013 at 15:45:27 UTC, eles wrote:
 which reminds me about the proposal to allow declaration of 
 static arrays with
 double[$] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];

Seems nice.
 double[4] foo = [1.0, 2.0];
 is accepted, which is a bit strange (I think the compiler 
 should give at least a warning if too many elements are 
 reserved for an array).

I just read that as "the other are NaN/.init initialized", which seems reasonable. The dollar notation is better than the warning here, to say that the array initializer is the authoritative source of the array length.
Apr 26 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 26 April 2013 at 15:59:32 UTC, Luís Marques wrote:
 On Friday, 26 April 2013 at 15:45:27 UTC, eles wrote:
 which reminds me about the proposal to allow declaration of 
 static arrays with
 double[$] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];

Seems nice.
 double[4] foo = [1.0, 2.0];
 is accepted, which is a bit strange (I think the compiler 
 should give at least a warning if too many elements are 
 reserved for an array).

I just read that as "the other are NaN/.init initialized", which seems reasonable. The dollar notation is better than the warning here, to say that the array initializer is the authoritative source of the array length.

I thought about it. However, it is not very nice. What if somebody types 1024 instead of 024 for an array length? The error could pass through the compiler and crash an out of memory after years of use. OTOH, I would like to be able to specify a partial initialization of the first elements of an array, then a default/imposed value for the remaining elements. So, what about: double[4] foo = [1.0, 2.0 .. ]; //initializes last 3 elements to 2.0 In this case, obviously, one cannot write double[$] foo = [1.0, 2.0 .. ]; //the compiler cannot deduce length of static array Speaking about the proposal of using "$" in declaring static arrays whose elements the compiler is able to count (just like in the double[$] foo = [1.0, 2.0];) I wonder sometimes why so much reluctance to implement those simple changes (and almost obvious), while other more dramatic changes are sometimes taken in a rush. Do not ask for examples, it is a feeling mainly derived from the discussions about those property-ies. Speaking about, what decision was reached to get rid of the compiler -property flag which is a monster per se? (changes the way the language is defined).
Apr 26 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 26 April 2013 at 14:58:35 UTC, Luís Marques wrote:
 Should this be supported?

     double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, 
 void];

 (it's not supported at the moment)

Why would you ever want this? I can't even think of a hypothetical use case.
Apr 26 2013
prev sibling next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:
On Friday, 26 April 2013 at 17:58:04 UTC, John Colvin wrote:
 Why would you ever want this? I can't even think of a 
 hypothetical use case.

The questions started as academic, motivated by the apparent lack of orthogonality. As far as a practical scenario, right now this is the best I can come up with: // emulator, ROM and RAM accessible from the same bus (von Neumann) byte[1024] romAndRam = [0x42, 0x77, 0xAF, 0x44, void]; (this relies also on eles' suggestion, the void is assumed for the remaining elements -- the RAM part). I'm not saying that this should be supported. I was asking if something like this should be :-)
Apr 26 2013
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 26 Apr 2013 07:58:34 -0700, Lu=C3=ADs Marques <luismarques gmail=
.com>  =

wrote:

 Should this be supported?

      double[8] foo =3D [1.0, 2.0, void, 3.0, 3.5, void, void, void];

 (it's not supported at the moment)

Have you considered what this does? Consider a standard [1.0, 2.0] call= : In essence, it pushes 1.0 and 2.0 onto the stack, then calls a function = to = allocate the memory and use the given data. What will end up happening is the data is copied from the stack to the = heap. It's just in your case, the data copied is garbage. I see little= = point in supporting this. -Steve
Apr 26 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/27/2013 07:29 AM, Steven Schveighoffer wrote:
 On Fri, 26 Apr 2013 07:58:34 -0700, Luís Marques <luismarques gmail.com>
 wrote:

 Should this be supported?

      double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];

 (it's not supported at the moment)

Have you considered what this does? Consider a standard [1.0, 2.0] call: In essence, it pushes 1.0 and 2.0 onto the stack, then calls a function to allocate the memory and use the given data. What will end up happening is the data is copied from the stack to the heap. It's just in your case, the data copied is garbage. I see little point in supporting this. -Steve

(This is a DMD performance bug.)
Apr 27 2013
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 27/04/2013 06:29, Steven Schveighoffer wrote:
<snip>
 Have you considered what this does?  Consider a standard [1.0, 2.0] call:

 In essence, it pushes 1.0 and 2.0 onto the stack, then calls a function
 to allocate the memory and use the given data.

Does it? I would have thought it stores the numbers in the static data segment, and uses a block memory copy in order to use it to initialise a static array. This would explain why initialising individual elements as void isn't supported. The point of initialising as void is to eliminate the overhead of initialising when you're just going to populate the array programmatically anyway. But with a block memory copy you can't skip over individual elements, so would have to initialise it bit by bit, which defeats the point since void is supposed to eliminate overhead, not create more. Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
May 16 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 27 April 2013 at 05:29:41 UTC, Steven Schveighoffer 
wrote:
 On Fri, 26 Apr 2013 07:58:34 -0700, Luís Marques 
 <luismarques gmail.com> wrote:

 Should this be supported?

     double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, 
 void];

 (it's not supported at the moment)

Have you considered what this does? Consider a standard [1.0, 2.0] call: In essence, it pushes 1.0 and 2.0 onto the stack, then calls a function to allocate the memory and use the given data. What will end up happening is the data is copied from the stack to the heap. It's just in your case, the data copied is garbage. I see little point in supporting this. -Steve

That is an implementation detail.
Apr 27 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 27 Apr 2013 06:43:58 -0700, deadalnix <deadalnix gmail.com> wrot=
e:

 On Saturday, 27 April 2013 at 05:29:41 UTC, Steven Schveighoffer wrote=

 On Fri, 26 Apr 2013 07:58:34 -0700, Lu=C3=ADs Marques  =


 <luismarques gmail.com> wrote:

 Should this be supported?

     double[8] foo =3D [1.0, 2.0, void, 3.0, 3.5, void, void, void];

 (it's not supported at the moment)

Have you considered what this does? Consider a standard [1.0, 2.0] =


 call:

 In essence, it pushes 1.0 and 2.0 onto the stack, then calls a functi=


 to allocate the memory and use the given data.

 What will end up happening is the data is copied from the stack to th=


 heap.  It's just in your case, the data copied is garbage.  I see  =


 little point in supporting this.

 -Steve

That is an implementation detail.

Oh, I didn't notice that foo was a fixed-sized array, I thought the focu= s = was on the array literal. It does make sense that this should be possible. -Steve
Apr 28 2013
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 17 May 2013 02:46:31 -0400, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 On 27/04/2013 06:29, Steven Schveighoffer wrote:
 <snip>
 Have you considered what this does?  Consider a standard [1.0, 2.0]  
 call:

 In essence, it pushes 1.0 and 2.0 onto the stack, then calls a function
 to allocate the memory and use the given data.

Does it? I would have thought it stores the numbers in the static data segment, and uses a block memory copy in order to use it to initialise a static array.

Last time I checked, that's what it did. But it may have changed. As Timon and deadalnix say, it's a bug in implementation. In any case, I was focusing only on the [] expression, not the fact that you are initializing a static array. The static array initialization should change how the expression is handled. -Steve
May 17 2013