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.
