a struct as an multidimensional array index

z z at z.com
Sat Jun 11 07:09:32 UTC 2022


On Saturday, 11 June 2022 at 03:56:32 UTC, Chris Katko wrote:
> On Friday, 10 June 2022 at 17:26:48 UTC, Ali Çehreli wrote:
>> On 6/10/22 08:13, z wrote:
>>
>> > arrays of arrays has different order for declaration and
>> addressing,
>> > and declaring array of arrays has different order depending
>> on how you
>> > declare it and wether it's static or dynamic array, *oof*)
>> >
>> > To give you an idea of the situation :
>> > ```D
>> >      int[3][1] a;//one array of 3 int
>> >      writeln(a[0][2]);//first "column", third "row"
>> > ```
>>
>> I've written about this multiple times in the past but D's way 
>> is consistent for me. That must be because I always found C's 
>> syntax to be very illogical on this. To me, C's problem starts 
>> with putting the variable name in the middle:
>>
>>   // C code:
>>   int a[1][3]; // Why?
>>
>> So, first, D moves the variable to its consistent place: after 
>> the type:
>>
>>   int i;
>>   int[N] arr;
>>
>> Both of those are in the form of "type and then name". Good...
>>
>> And then, here is the consistency with arrays: "type and then 
>> square brackets".
>>
>>   int[] dynamicArray;
>>   int[N] staticArray;
>>
>> So, here is where you and I differ:
>>
>>   int[3][1] arr;  // Ali likes
>>   int[1][3] arr;  // z wants
>>
>> I like it because it is consistently "type and then square 
>> brackets". (It so happens that the type of each element is 
>> int[N] in this case.) If it were the other way, than array 
>> syntax would be inconsistent with itself. :) Or, we would have 
>> to accept that it is inside-out like in C.
>>
>> But of course I understand how it is seen as consistent from 
>> C's point of view. :)
>>
>> And this is consistent with static vs dynamic as well because 
>> again it's "type and then square brackets":
>>
>>   int[1][] a;  // A dynamic array of int[1]
>>   int[][3] b;  // A static array of 3 int[]s
>>
>> Ali
>
> This is an interesting discussion. I had noticed multi-dim 
> arrays seemed backwards but I assumed I was doing something 
> wrong and had other thing to worry about. I had no idea it was 
> DIFFERENT for static vs dynamic arrays? That's horrifying!
>
> Also you reminded me of a possible D bug that I ran into. I had 
> classes that had circular dependencies. One had to know about 
> the other, and vice-versa. And I had derived classes. But 
> somehow, they would explode. I would send one reference to the 
> others constructor to 'link' them together, but the reference 
> would be NULL. But if I accessed the exact same variable 
> through a global reference, it worked fine.
>
> I tried ripping the affected code into a new file but the bug 
> wasn't replicated. Even if I matched the compiler/linker 
> options. It was super frustrating.

I rechecked and it should be `X Y Z` for static array, but `Z Y 
X` for indexing/dynamic array creating with `new`
(e.g. `float[][][] arr = new 
float[][][](third_dimension,second_dimension,first_dimension;`)

The dillema is that alone, the orders are sound byproducts of the 
language rules, it's when they are put in relation to each other 
that it can become weird.

The bug could also be one of those implementation-specific bugs 
that are seemingly impossible to reproduce minimally because they 
require unknown very specific conditions to occur. Self and inter 
referencing appears unstable whenever it is not in the 
module/global scope.


More information about the Digitalmars-d-learn mailing list