www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - multi-dimensional array whole slicing

reply XavierAP <n3minis-git yahoo.es> writes:
I can do:

int[3] arr = void;
arr[] = 1;

But apparently I can't do:

int[3][4] arr = void;
arr[][] = 1;

What is the best way? What am I missing?
Apr 22
next sibling parent reply kinke <noone nowhere.com> writes:
On Saturday, 22 April 2017 at 20:51:46 UTC, XavierAP wrote:
 I can do:

 int[3] arr = void;
 arr[] = 1;

 But apparently I can't do:

 int[3][4] arr = void;
 arr[][] = 1;

 What is the best way? What am I missing?
int[3][4] arr = void; (cast(int[]) arr)[] = 1; assert(arr[3][2] == 1);
Apr 22
parent XavierAP <n3minis-git yahoo.es> writes:
On Saturday, 22 April 2017 at 22:25:58 UTC, kinke wrote:
 int[3][4] arr = void;
 (cast(int[]) arr)[] = 1;
 assert(arr[3][2] == 1);
Thanks... I think I prefer to write two loops though :p I wish D built-in arrays supported [,] indexing notation like C# (or as you can do in D for custom types)
Apr 23
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 04/22/2017 01:51 PM, XavierAP wrote:
 I can do:

 int[3] arr = void;
 arr[] = 1;

 But apparently I can't do:

 int[3][4] arr = void;
 arr[][] = 1;

 What is the best way? What am I missing?
It took me a while to convince myself that there is no bug here. The problem, as is obvious to others, ;) a whole slice of a whole slice is still the same slice. So it's not possible to go deeper into the element slices. Here is a proof with a simple array: int[] a; static assert(is(typeof(a[]) == typeof(a[][][][]))); Ali
Apr 23
parent reply XavierAP <n3minis-git yahoo.es> writes:
On Sunday, 23 April 2017 at 09:06:35 UTC, Ali Çehreli wrote:
 It took me a while to convince myself that there is no bug 
 here. The problem, as is obvious to others, ;) a whole slice of 
 a whole slice is still the same slice.
Ha, you're right, I hadn't realized. But I still have a problem. For both multi-dimensional and uni-dimensional arrays a[] and a[][] are the same. And yet, a[] has different type in both cases and a[]=1 compiles for uni-dimensional but not for multi-dimensional.
Apr 23
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 04/23/2017 12:04 PM, XavierAP wrote:

 For both multi-dimensional and
 uni-dimensional arrays a[] and a[][] are the same. And yet, a[] has
 different type in both cases and a[]=1 compiles for uni-dimensional but
 not for multi-dimensional.
I think it's still consistent because the element type is not int in the case of multi-dimensional arrays. The following makes sense to me but I haven't profiled it. Otherwise, kinke's solution is perfectly fine in a system programming language. ;) int[3] a; a[] = 1; a[][] = 1; // Same effect int[3][4] b; b[] = [1, 1, 1]; b[][] = [1, 1, 1]; // Same effect Ali
Apr 25
parent XavierAP <n3minis-git yahoo.es> writes:
On Tuesday, 25 April 2017 at 20:46:24 UTC, Ali Çehreli wrote:
 I think it's still consistent because the element type is not 
 int in the case of multi-dimensional arrays.
 [...]
     int[3][4] b;
     b[] = [1, 1, 1];
It is consistent, I just miss the possibility to more easily initialize multi-dimensional arrays uniformly in the same way as uni-dimensional ones. I do not mean it would be good to change the current behavior. I think the best solution would be for D to implement built-in truly multi-dimensional arrays like T[,] as well as the existing (jagged) arrays of arrays T[][]. That's what C# does. The former could maybe even be lowered into jagged arrays (together with their initializations and slicings). But again most people probably don't miss T[,] built-in arrays, specially since we can implement such [,] indexing for custom types. So there's not a strong use case. But actually where I'm using multi-dimensional built-in arrays right now is in the private storage of a custom multi-dimensional type. Then I have the choice of either use them and live with this, but forward indexing transparently; or use uni-dimensional as private storage and map from 2d to linear during indexing...
Apr 25