www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Array declaration warning

reply "Paul" <paul example.com> writes:
This array of structures...

CoOrd pathList[NumPaths][];

generates a warning when compiled with DMD 32 bit -w flag, but 
not 64 bit.

If I correct the declaration to 'D style'

CoOrd[NumPaths][] pathList;

It compiles without warning but I cannot append items to the 
array like this...

pathList[n] ~= CoOrd(cX, cY);

What am I doing wrong?

TIA

Paul
Jun 02 2015
next sibling parent reply "Alex Parrill" <initrd.gz gmail.com> writes:
On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:

 This array of structures...

 CoOrd pathList[NumPaths][];

 generates a warning when compiled with DMD 32 bit -w flag, but 
 not 64 bit.


This gives me a warning using rdmd on x64 XUbuntu.


 If I correct the declaration to 'D style'

 CoOrd[NumPaths][] pathList;

 It compiles without warning but I cannot append items to the 
 array like this...

 pathList[n] ~= CoOrd(cX, cY);

 What am I doing wrong?


`CoOrd[NumPaths]` is a fixed-length array type containing 
`NumPaths` elements. You can't append to it. `CoOrd[NumPaths][]` 
is a dynamic array of such arrays, but `pathList[n]` gets one of 
the fixed-length arrays from the dynamic array.

Perhaps you mean `CoOrd[][NumPaths]`?
Jun 02 2015
parent "Paul" <paul example.com> writes:
On Tuesday, 2 June 2015 at 16:22:58 UTC, Alex Parrill wrote:

 On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:

 This array of structures...

 CoOrd pathList[NumPaths][];

 generates a warning when compiled with DMD 32 bit -w flag, but 
 not 64 bit.


 This gives me a warning using rdmd on x64 XUbuntu.


 If I correct the declaration to 'D style'

 CoOrd[NumPaths][] pathList;

 It compiles without warning but I cannot append items to the 
 array like this...

 pathList[n] ~= CoOrd(cX, cY);

 What am I doing wrong?


 `CoOrd[NumPaths]` is a fixed-length array type containing 
 `NumPaths` elements. You can't append to it. 
 `CoOrd[NumPaths][]` is a dynamic array of such arrays, but 
 `pathList[n]` gets one of the fixed-length arrays from the 
 dynamic array.

 Perhaps you mean `CoOrd[][NumPaths]`?


Thank you, i guess that will work although it doesn't fit with my 
way of thinking about the problem, ie there are a fixed number of 
paths of variable length, eg...
pathList[0] (43, 60), (44, 60) ... <- append items
pathList[1] (55, 801), (56, 802), (56, 803) .... <- append items
pathList[2] etc

In case it's of interest I was compiling on Mint 17 64bit and 
Mint 17.1 32bit, both with latest DMD.
Jun 02 2015
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:

 CoOrd[NumPaths][] pathList;


Try CoOrd[][NumPaths].

The order is opposite in D style than in C style (I thnk the D 
style makes more sense, it just reads one direction, but it does 
index differently than you're used to in C)
Jun 02 2015
next sibling parent reply "Paul" <paul example.com> writes:
On Tuesday, 2 June 2015 at 16:23:32 UTC, Adam D. Ruppe wrote:

 On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:

 CoOrd[NumPaths][] pathList;


 Try CoOrd[][NumPaths].

 The order is opposite in D style than in C style (I thnk the D 
 style makes more sense, it just reads one direction, but it 
 does index differently than you're used to in C)


Thank you - I can see this will cause me no end of problems until 
I get my head 'round it!

Paul
Jun 02 2015
parent reply Mike Parker <aldacron gmail.com> writes:
On 6/3/2015 1:37 AM, Paul wrote:

 On Tuesday, 2 June 2015 at 16:23:32 UTC, Adam D. Ruppe wrote:

 On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:

 CoOrd[NumPaths][] pathList;


 Try CoOrd[][NumPaths].

 The order is opposite in D style than in C style (I thnk the D style
 makes more sense, it just reads one direction, but it does index
 differently than you're used to in C)


 Thank you - I can see this will cause me no end of problems until I get
 my head 'round it!


int[] -> A dynamic array of int
int*[] -> A dynamic array of int*
int[][] -> A a dynamic array of int[]

int[3] -> a static array of int
int*[3] -> a static array of int*
int[][3] -> a static array of int[]
Jun 02 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/2/15 9:43 PM, Mike Parker wrote:

 On 6/3/2015 1:37 AM, Paul wrote:

 On Tuesday, 2 June 2015 at 16:23:32 UTC, Adam D. Ruppe wrote:

 On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:

 CoOrd[NumPaths][] pathList;


 Try CoOrd[][NumPaths].

 The order is opposite in D style than in C style (I thnk the D style
 makes more sense, it just reads one direction, but it does index
 differently than you're used to in C)


 Thank you - I can see this will cause me no end of problems until I get
 my head 'round it!


 int[] -> A dynamic array of int
 int*[] -> A dynamic array of int*
 int[][] -> A a dynamic array of int[]

 int[3] -> a static array of int
 int*[3] -> a static array of int*
 int[][3] -> a static array of int[]


To further demonstrate the logic of the grammar:

An array looks like this:

T[]

Where T is some type.

So whenever you see this pattern, you know this is an array of that 
type, even if that type is more arrays!

int[] => T == int
int*[] => T == int*
int[][] => T == int[]

The same works for static arrays, except those have a builtin length.

It's actually quite simple and logical. What can confuse people is when 
using the array, you reverse the indices:

int[4][3] arr; // A static array of 3 elements, each element is a static 
array of 4 elements of int.

So the length of the indexes is reversed, the first position has length 
of 3, the second has length of 4.

-Steve
Jun 02 2015
prev sibling parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
I used to not even notice that if D declare an array in C-style, 
and then indexing it will also in C-style :)
Actually, I have a small question. And what is the advantage of 
indexing arrays D-style in front of a C-style arrays? Because 
C-style indexing is much more familiar: first, we point line, and 
then the columns.

import std.algorithm;

void main() {

     int cArr[2][4];
     assert(equal(cArr[], [[0, 0, 0, 0],
                           [0, 0, 0, 0]]));

     int[2][4] dArr;
     assert(equal(dArr[], [[0, 0],
			  [0, 0],
                           [0, 0],
                           [0, 0]]));
}
Jun 02 2015
parent reply "Paul" <paul example.com> writes:
On Wednesday, 3 June 2015 at 02:41:01 UTC, Dennis Ritchie wrote:

 Actually, I have a small question. And what is the advantage of 
 indexing arrays D-style in front of a C-style arrays? Because 
 C-style indexing is much more familiar: first, we point line, 
 and then the columns.


That's what I meant by 'getting my head around it' - the concept
is simple enough, it's the years of habit that will be difficult
to break!

Paul
Jun 03 2015
parent reply "Paul" <paul example.com> writes:
On Wednesday, 3 June 2015 at 11:42:35 UTC, Paul wrote:

the concept is simple enough...


Well I thought it was; everything works as expected but I need to 
access values in the c style, i.e g the definitions:

struct CoOrd
{
int x, y;
}

CoOrd[][NumPaths]pathList;
Jun 03 2015
parent reply "Paul" <paul example.com> writes:
Ooops, this is what I meant to post:

struct CoOrd
{
	int x, y;
}

CoOrd[][NumPaths]pathList;


I append values like so...

pathList[][n] ~= CoOrd(cX, cY);

But to get the expected values, I need to access them like this 
example for last x co-ord of last item:


int xx = pathList[NumPaths-1][$ - 1].x;


Doesn't seem right (but it works)...
Jun 03 2015
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/03/2015 01:28 PM, Paul wrote:


 Ooops, this is what I meant to post:

 struct CoOrd
 {
      int x, y;
 }

 CoOrd[][NumPaths]pathList;


 I append values like so...

 pathList[][n] ~= CoOrd(cX, cY);


I don't think you need the empty [] there. pathList[n] is one of the 
paths and you are adding a coordinate to it:

     pathList[n] ~= CoOrd(cX, cY);


 But to get the expected values, I need to access them like this example
 for last x co-ord of last item:


 int xx = pathList[NumPaths-1][$ - 1].x;


 Doesn't seem right (but it works)...


I makes perfect sense! ;) pathList[NumPaths-1] is the last path and you 
are accessing the last coordinate in it. C did it wrong. Luckily, I've 
always found C's syntax unbelievably backward (or inside-out?).

Ali
Jun 03 2015
parent reply "Paul" <paul example.com> writes:
On Wednesday, 3 June 2015 at 20:33:02 UTC, Ali Çehreli wrote:

 pathList[][n] ~= CoOrd(cX, cY);


 I don't think you need the empty [] there. pathList[n] is one 
 of the paths and you are adding a coordinate to it:


Urgh, *that* is how I was confusing myself, the rest of the code 
'looks right'. Strange that it compiles without warning and the 
spurious [] have no effect though. No doubt there is a reason for 
this that I probably won't understand!

Thanks again

Paul
Jun 03 2015
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/03/2015 01:45 PM, Paul wrote:


 On Wednesday, 3 June 2015 at 20:33:02 UTC, Ali Çehreli wrote:

 pathList[][n] ~= CoOrd(cX, cY);


 I don't think you need the empty [] there. pathList[n] is one of the
 paths and you are adding a coordinate to it:


 Urgh, *that* is how I was confusing myself, the rest of the code 'looks
 right'. Strange that it compiles without warning and the spurious []
 have no effect though.


[] means "a slice to all elements". There is no difference in your code 
because pathList is already "a slice to all elements".

Here are a couple of use cases:

1) Being able to traverse a fixed-length array as a range:

import std.stdio;
import std.algorithm;

void main()
{
     int[2] arr = [ 1, 2 ];

     writeln(arr.map!(a => a * 10)); // COMPILATION ERROR
}

The last line cannot be compiled because a fixed-length array cannot 
provide popFront() because its length cannot be changed.

The fix is to slice all elements first by inserting []:

     writeln(arr[].map!(a => a * 10));

There, arr[] is a temporary slice that gets consumed as a range.


2) [] enables array-wise operations:

     int[] arr = [ 1, 2 ];
     arr[] *= 10;    // Multiplies all elements by 10

     arr[] = 42;     // sets all elements to 42


Note the important difference it makes here:

     int[] a = [ 1, 2 ];
     int[] b = [ 3, 4 ];

     a[] = b;    // makes the elements of 'a' same as 'b's elements
     a = b;      // makes 'a' be another slice to 'b's elements

You won't see any difference between the two lines above if you print 
'a', but in the first case a.ptr != b.ptr and in the second case a.ptr 
== b.ptr.

Ali
Jun 03 2015
parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 3 June 2015 at 21:05:42 UTC, Ali Çehreli wrote:

 On 06/03/2015 01:45 PM, Paul wrote:


 On Wednesday, 3 June 2015 at 20:33:02 UTC, Ali Çehreli wrote:

 pathList[][n] ~= CoOrd(cX, cY);


 I don't think you need the empty [] there. pathList[n] is




 one of the

 paths and you are adding a coordinate to it:


 Urgh, *that* is how I was confusing myself, the rest of the


 code 'looks

 right'. Strange that it compiles without warning and the


 spurious []

 have no effect though.


 [] means "a slice to all elements". There is no difference in 
 your code because pathList is already "a slice to all elements".

 Here are a couple of use cases:

 1) Being able to traverse a fixed-length array as a range:

 import std.stdio;
 import std.algorithm;

 void main()
 {
     int[2] arr = [ 1, 2 ];

     writeln(arr.map!(a => a * 10)); // COMPILATION ERROR
 }

 The last line cannot be compiled because a fixed-length array 
 cannot provide popFront() because its length cannot be changed.

 The fix is to slice all elements first by inserting []:

     writeln(arr[].map!(a => a * 10));

 There, arr[] is a temporary slice that gets consumed as a range.


 2) [] enables array-wise operations:

     int[] arr = [ 1, 2 ];
     arr[] *= 10;    // Multiplies all elements by 10

     arr[] = 42;     // sets all elements to 42


 Note the important difference it makes here:

     int[] a = [ 1, 2 ];
     int[] b = [ 3, 4 ];

     a[] = b;    // makes the elements of 'a' same as 'b's 
 elements
     a = b;      // makes 'a' be another slice to 'b's elements

 You won't see any difference between the two lines above if you 
 print 'a', but in the first case a.ptr != b.ptr and in the 
 second case a.ptr == b.ptr.

 Ali


Isn't a[] = b deprecated syntax? I believe you have to use a[] = 
b[] now.
Jun 04 2015
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/04/2015 04:27 AM, Meta wrote:

 On Wednesday, 3 June 2015 at 21:05:42 UTC, Ali Çehreli wrote:



     a[] = b;    // makes the elements of 'a' same as 'b's elements





 Isn't a[] = b deprecated syntax? I believe you have to use a[] = b[] now.


Thanks. Unfortunately, 2.067.1 'dmd -w -de' is still quiet about that one.

Ali
Jun 04 2015
parent "Meta" <jared771 gmail.com> writes:
On Thursday, 4 June 2015 at 16:52:30 UTC, Ali Çehreli wrote:

 On 06/04/2015 04:27 AM, Meta wrote:

 On Wednesday, 3 June 2015 at 21:05:42 UTC, Ali Çehreli wrote:



     a[] = b;    // makes the elements of 'a' same as 'b's




 elements


 Isn't a[] = b deprecated syntax? I believe you have to use


 a[] = b[] now.

 Thanks. Unfortunately, 2.067.1 'dmd -w -de' is still quiet 
 about that one.

 Ali


Then maybe I'm wrong. I was sure, though, that Andrei created a 
thread complaining about the change sometime last year (which is 
why I remember that it was changed in the first place).
Jun 04 2015
prev sibling parent reply "anonymous" <anonymous example.com> writes:
On Wednesday, 3 June 2015 at 20:28:57 UTC, Paul wrote:

 Ooops, this is what I meant to post:

 struct CoOrd
 {
 	int x, y;
 }

 CoOrd[][NumPaths]pathList;


 I append values like so...

 pathList[][n] ~= CoOrd(cX, cY);


The "[]" does nothing here. You can leave it (or add more) out 
without changing the meaning:

pathList[][n] ~= CoOrd(cX, cY);
pathList[n] ~= CoOrd(cX, cY);
pathList[][][n] ~= CoOrd(cX, cY);

... all the same.


 But to get the expected values, I need to access them like this 
 example for last x co-ord of last item:


 int xx = pathList[NumPaths-1][$ - 1].x;


 Doesn't seem right (but it works)...


Declarations are right to left, accesses are left to right. 
NumPaths is on the right in the declaration, and it's on the left 
in the access. Makes sense to me.
Jun 03 2015
parent "Paul" <paul example.com> writes:
On Wednesday, 3 June 2015 at 20:38:54 UTC, anonymous wrote:

 Declarations are right to left, accesses are left to right.


Succinctly put, even I should be able to remember that.

Paul
Jun 03 2015