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