www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Simple array init question

reply Graham <grahamamacdonald gmail.com> writes:
Why will array setting work for a 1D array, but not a 2D?  If I enter:
   int[5] buffer;
   buffer[] = 5;

It compiles, but if I enter:
   int[5][5] buffer;
   buffer[][] = 5;

(I tried the variation buffer[] = 5, but that didn't work either.)

It fails to compile (in gdc), with the warning:

   MainLoop.d:56: Error: cannot implicitly convert expression (5) of 
type int to int[5]
   Error: cannot cast int to int[5]
   make: *** [build/MainLoop.o] Error 1

To my untrained eye, it looks like it would like me to pass it an int[5] 
to initialize the array, but that's a bit odd - I'd much rather treat it 
similarly to a 1D array in this case!

Thanks,
graham
Apr 07 2007
next sibling parent reply Paul Findlay <r.lph50+d gmail.com> writes:
 It compiles, but if I enter:
    int[5][5] buffer;
    buffer[][] = 5;

Have you tried: int[5][5] buffer; buffer[] = [5,5,5,5,5]; // or something (Or try in the digitalmars.D.learn newgroup) - Paul
Apr 07 2007
parent reply Graham <grahamamacdonald gmail.com> writes:
Thanks for your reply.  No, I didn't try that, since the array I'm 
actually using is several thousand elements large.


Paul Findlay wrote:
 It compiles, but if I enter:
    int[5][5] buffer;
    buffer[][] = 5;

Have you tried: int[5][5] buffer; buffer[] = [5,5,5,5,5]; // or something (Or try in the digitalmars.D.learn newgroup) - Paul

Apr 07 2007
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Graham wrote:
 Thanks for your reply.  No, I didn't try that, since the array I'm 
 actually using is several thousand elements large.
 
 
 Paul Findlay wrote:
 It compiles, but if I enter:
    int[5][5] buffer;
    buffer[][] = 5;

Have you tried: int[5][5] buffer; buffer[] = [5,5,5,5,5]; // or something (Or try in the digitalmars.D.learn newgroup) - Paul


In which case you've got two immediate options, and a third option requiring a library. :) Immediate #1 - Use a loop (possibly wrapped in a function) to init the array. Immediate #2 - Use a typedef of the array's element type with a custom init value -- unfortunately this is rarely realistic as typedef types are strong in D. Library option - Use Cashew (cashew.utils.Array) thusly: int[1024][1024] buf = repeat(repeat(5, 1024_U), 1024_U); (Admittedly untested, but it should work fine. Cashew is available from DSource.) http://www.dsource.org/projects/cashew When it comes right down to it, I actually have to admit to wishing the '[][] = 5' approach worked. Hm. -- Chris Nicholson-Sauls
Apr 07 2007
parent Graham <grahamamacdonald gmail.com> writes:
The 1st is what I went for.  Not being able to initialise a 
multidimensional array using the same syntax as a one dimensional array 
seems a bit inconsistent - either a bug or an omission - so I figured 
I'd mention it here.

Thanks.

Chris Nicholson-Sauls wrote:
 In which case you've got two immediate options, and a third option 
 requiring a library.  :)
 
 Immediate #1 - Use a loop (possibly wrapped in a function) to init the 
 array.
 
 Immediate #2 - Use a typedef of the array's element type with a custom 
 init value -- unfortunately this is rarely realistic as typedef types 
 are strong in D.
 
 Library option - Use Cashew (cashew.utils.Array) thusly:
 int[1024][1024] buf = repeat(repeat(5, 1024_U), 1024_U);
 
 (Admittedly untested, but it should work fine.  Cashew is available from 
 DSource.)
 http://www.dsource.org/projects/cashew
 
 
 When it comes right down to it, I actually have to admit to wishing the 
 '[][] = 5' approach worked.  Hm.
 
 -- Chris Nicholson-Sauls

Apr 07 2007
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Graham wrote

 several thousand elements large.

In what domains do one need to represent dense multidimensional structures with O(1) time for accesses of elements? -manfred
Apr 07 2007
parent reply Graham <grahamamacdonald gmail.com> writes:
A floating point texture buffer - 3 floats per pixel, and (say) 640x480 
pixels.

Manfred Nowak wrote:
 Graham wrote
 
 several thousand elements large.

In what domains do one need to represent dense multidimensional structures with O(1) time for accesses of elements? -manfred

Apr 07 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Graham wrote:
 A floating point texture buffer - 3 floats per pixel, and (say) 640x480
 pixels.
 
 Manfred Nowak wrote:
 Graham wrote

 several thousand elements large.

In what domains do one need to represent dense multidimensional structures with O(1) time for accesses of elements? -manfred


Perhaps you shouldn't be using jagged arrays, then. int[][] is *NOT* a multidimensional array. It's basically equivalent to this: struct int_array { int* ptr; size_t length; } struct int_array_array { int_array* ptr; size_t length; } int_array_array buffer; Notice those nested pointers; that means that your texture is not necessarily contiguous in memory, which would make, for example, loading the texture into GL a pain in the behind. Not sure if the cache would have problems... I think there's a few multidimensional array templates floating around... or if not, you can always write your own :) -- Daniel -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Apr 07 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Daniel Keep wrote:
 
 Graham wrote:
 A floating point texture buffer - 3 floats per pixel, and (say) 640x480
 pixels.

 Manfred Nowak wrote:
 Graham wrote

 several thousand elements large.

structures with O(1) time for accesses of elements? -manfred


Perhaps you shouldn't be using jagged arrays, then. int[][] is *NOT* a multidimensional array. It's basically equivalent to this: struct int_array { int* ptr; size_t length; } struct int_array_array { int_array* ptr; size_t length; } int_array_array buffer; Notice those nested pointers; that means that your texture is not necessarily contiguous in memory, which would make, for example, loading the texture into GL a pain in the behind. Not sure if the cache would have problems... I think there's a few multidimensional array templates floating around... or if not, you can always write your own :) -- Daniel

Actually, /IF/ he's using static/fixed-length arrays, then as I understand it this ceases to be true. That is, static arrays are solid blocks of memory -- and I assume this stays the same for multi-dimensional arrays. Of course, /IF/ he's using dynamic-length arrays, then you're absolutely correct about it being likely opposite. -- Chris Nicholson-Sauls
Apr 07 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Chris Nicholson-Sauls wrote:
 Daniel Keep wrote:
 Graham wrote:
 A floating point texture buffer - 3 floats per pixel, and (say) 640x480
 pixels.

 Manfred Nowak wrote:
 Graham wrote

 several thousand elements large.

structures with O(1) time for accesses of elements? -manfred


Perhaps you shouldn't be using jagged arrays, then. int[][] is *NOT* a multidimensional array. It's basically equivalent to this: struct int_array { int* ptr; size_t length; } struct int_array_array { int_array* ptr; size_t length; } int_array_array buffer; Notice those nested pointers; that means that your texture is not necessarily contiguous in memory, which would make, for example, loading the texture into GL a pain in the behind. Not sure if the cache would have problems... I think there's a few multidimensional array templates floating around... or if not, you can always write your own :) -- Daniel

Actually, /IF/ he's using static/fixed-length arrays, then as I understand it this ceases to be true. That is, static arrays are solid blocks of memory -- and I assume this stays the same for multi-dimensional arrays. Of course, /IF/ he's using dynamic-length arrays, then you're absolutely correct about it being likely opposite. -- Chris Nicholson-Sauls

Ah yes, of course. Sorry; bit dense today :P -- Daniel -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Apr 07 2007
parent reply Graham <grahamamacdonald gmail.com> writes:
A bit of confusion here:-)  Yes, it's a simple, static fixed size, 
multi-dimensional array.  I could use a 1D array, but I wanted to try 
out the 2D approach and was puzzled why I couldn't use the initialiser 
for the entire array if I had more than one dimension.  There's nothing 
more to this!

Thanks.

Daniel Keep wrote:
 
 Chris Nicholson-Sauls wrote:
 Daniel Keep wrote:
 Graham wrote:
 A floating point texture buffer - 3 floats per pixel, and (say) 640x480
 pixels.

 Manfred Nowak wrote:
 Graham wrote

 several thousand elements large.

structures with O(1) time for accesses of elements? -manfred


multidimensional array. It's basically equivalent to this: struct int_array { int* ptr; size_t length; } struct int_array_array { int_array* ptr; size_t length; } int_array_array buffer; Notice those nested pointers; that means that your texture is not necessarily contiguous in memory, which would make, for example, loading the texture into GL a pain in the behind. Not sure if the cache would have problems... I think there's a few multidimensional array templates floating around... or if not, you can always write your own :) -- Daniel

understand it this ceases to be true. That is, static arrays are solid blocks of memory -- and I assume this stays the same for multi-dimensional arrays. Of course, /IF/ he's using dynamic-length arrays, then you're absolutely correct about it being likely opposite. -- Chris Nicholson-Sauls

Ah yes, of course. Sorry; bit dense today :P -- Daniel

Apr 08 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Graham wrote:
 A bit of confusion here:-)  Yes, it's a simple, static fixed size,
 multi-dimensional array.  I could use a 1D array, but I wanted to try
 out the 2D approach and was puzzled why I couldn't use the initialiser
 for the entire array if I had more than one dimension.  There's nothing
 more to this!
 
 Thanks.

You *don't* have more than one dimension; you're really nesting arrays. Strictly speaking, int[5][5] is an (albeit static) jagged array. I realise that for your purposes, it's six of one, half a dozen of the other -- I'm just being pedantic :) -- Daniel
 Daniel Keep wrote:
 Chris Nicholson-Sauls wrote:
 Daniel Keep wrote:
 Graham wrote:
 A floating point texture buffer - 3 floats per pixel, and (say)
 640x480
 pixels.

 Manfred Nowak wrote:
 Graham wrote

 several thousand elements large.

structures with O(1) time for accesses of elements? -manfred


multidimensional array. It's basically equivalent to this: struct int_array { int* ptr; size_t length; } struct int_array_array { int_array* ptr; size_t length; } int_array_array buffer; Notice those nested pointers; that means that your texture is not necessarily contiguous in memory, which would make, for example, loading the texture into GL a pain in the behind. Not sure if the cache would have problems... I think there's a few multidimensional array templates floating around... or if not, you can always write your own :) -- Daniel

understand it this ceases to be true. That is, static arrays are solid blocks of memory -- and I assume this stays the same for multi-dimensional arrays. Of course, /IF/ he's using dynamic-length arrays, then you're absolutely correct about it being likely opposite. -- Chris Nicholson-Sauls

Ah yes, of course. Sorry; bit dense today :P -- Daniel


-- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Apr 08 2007
parent reply Graham <grahamamacdonald gmail.com> writes:
As I said before, I could use a normal 1D array.  My basic point is that 
as I was trying to initialise a static, rectangular array, there's no 
reason (that I can see) why the initialiser can't work for more than 1D.

(And to be pedantic, int[5][5] is a 2D rectangular array, which in 
memory is exactly the same as int[25] - a 1D array, of course - so six 
of one and half a dozen of the other perhaps, but int[5][5] does have > 
1 dimension :-))

(Thanks for the previous recommendations though!)

g

Daniel Keep wrote:
 You *don't* have more than one dimension; you're really nesting arrays.
  Strictly speaking, int[5][5] is an (albeit static) jagged array.
 
 I realise that for your purposes, it's six of one, half a dozen of the
 other -- I'm just being pedantic :)
 
 	-- Daniel

Apr 08 2007
parent reply Dan <murpsoft hotmail.com> writes:
Graham Wrote:
 (And to be pedantic, int[5][5] is a 2D rectangular array, which in 
 memory is exactly the same as int[25] - a 1D array, of course - so six 
 of one and half a dozen of the other perhaps, but int[5][5] does have > 
 1 dimension :-))

Actually, you're wrong sir. An int[5][5] produces an array containing 5 structs, each of: struct Array { size_t(or was it int? uint?) length; void* ptr; } Each of those arrays then points to another array of 5 elements. What I believe you want is a rectangular array: int[5,5], which will produce a single Array struct that you can access via taking a multiple of the first index added to the second index (or is it vice versa?) This notation tends to typically be inferior to int[25] for that very reason, each access requires math on two indices. I might also note that it is typically more efficient to use a power of two for array sizes for indexing purposes - so long as the array size doesn't cause the OS you're working on to have difficulty allocating the space. Some OS's allocate in 4kb units and then take 16 bytes for metadata, some allocate anything > 2kb in a "giant data" page-set which may be more inefficient than the smaller page-sets as it may allocate your data accross pages.
Apr 09 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Dan wrote:
 Graham Wrote:
 (And to be pedantic, int[5][5] is a 2D rectangular array, which in 
 memory is exactly the same as int[25] - a 1D array, of course - so six 
 of one and half a dozen of the other perhaps, but int[5][5] does have > 
 1 dimension :-))

Actually, you're wrong sir. An int[5][5] produces an array containing 5 structs, each of: struct Array { size_t(or was it int? uint?) length; void* ptr; } Each of those arrays then points to another array of 5 elements.

No, he was right. That struct is only used for dynamic arrays, not with static arrays. Static arrays are just a linear row of members stored in-place (but passed by reference). You don't need to take my word for it, look at what the compilers do: ===== $ cat test.d import std.stdio; int[5][5] matrix; void main() { // Initialize foreach (r, inout row; matrix) { foreach (c, inout elt; row) { elt = r * 5 + c; } } // Access as a linear array: uint* p = cast(uint*) matrix.ptr; // (Note: ".ptr" is not actually stored but inserted as // a constant) for (size_t i = 0; i < 25; i++) { writef(p[i],' '); } writefln(); } $ dmd -run test.d 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 $ gdc -o test test.d && ./test 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 =====
 What I believe you want is a rectangular array:
 
 int[5,5], which will produce a single Array struct that you can access via
taking a multiple of the first index added to the second index (or is it vice
versa?)

Sorry, "int[5,5]" only compiles because of the obscure comma operator. The first 5 is evaluated and thrown away, what's left is a regular old int[5]. (Still stored in-place by the way)
 This notation tends to typically be inferior to int[25] for that very reason,
each access requires math on two indices.  I might also note that it is
typically more efficient to use a power of two for array sizes for indexing
purposes - so long as the array size doesn't cause the OS you're working on to
have difficulty allocating the space.

Providing two indices to a variable declared as "int[5,5]" will evaluate the first index and throw it away, only using the second. The comma operator strikes again.
 Some OS's allocate in 4kb units and then take 16 bytes for metadata, some
allocate anything > 2kb in a "giant data" page-set which may be more
inefficient than the smaller page-sets as it may allocate your data accross
pages.

Apr 09 2007
parent reply Dan <murpsoft hotmail.com> writes:
Frits van Bommel Wrote:

 Dan wrote:
 Graham Wrote:
 (And to be pedantic, int[5][5] is a 2D rectangular array, which in 
 memory is exactly the same as int[25] - a 1D array, of course - so six 
 of one and half a dozen of the other perhaps, but int[5][5] does have > 
 1 dimension :-))

Actually, you're wrong sir. An int[5][5] produces an array containing 5 structs, each of: struct Array { size_t(or was it int? uint?) length; void* ptr; } Each of those arrays then points to another array of 5 elements.

No, he was right. That struct is only used for dynamic arrays, not with static arrays. Static arrays are just a linear row of members stored in-place (but passed by reference). You don't need to take my word for it, look at what the compilers do: ===== $ cat test.d import std.stdio; int[5][5] matrix; void main() { // Initialize foreach (r, inout row; matrix) { foreach (c, inout elt; row) { elt = r * 5 + c; } } // Access as a linear array: uint* p = cast(uint*) matrix.ptr; // (Note: ".ptr" is not actually stored but inserted as // a constant) for (size_t i = 0; i < 25; i++) { writef(p[i],' '); } writefln(); } $ dmd -run test.d 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 $ gdc -o test test.d && ./test 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 =====

Fascinating. I thought static arrays were implemented in the same way (in terms of structure) as dynamic arrays. I'm curious then if I declare a: struct z { int[] y; } static z[] x = [ { y:[1,2,3] } ]; Does this implement a static array, or a dynamic array? I *hope* a dynamic one, as otherwise I will have to rewrite my entire Global_init routine for Walnut 2.x. : o
 What I believe you want is a rectangular array:
 
 int[5,5], which will produce a single Array struct that you can access via
taking a multiple of the first index added to the second index (or is it vice
versa?)

Sorry, "int[5,5]" only compiles because of the obscure comma operator.

According to the D spec, that should compile as a rectangular array. I haven't tried it. I have read the spec. See: http://digitalmars.com/d/arrays.html and visit "Rectangular Arrays". PS: Walter, any chance we can get <a name=""> so we can link directly to specific parts of the spec?
Apr 09 2007
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Dan" <murpsoft hotmail.com> wrote in message 
news:evem9b$a9p$1 digitalmars.com...
 Fascinating.  I thought static arrays were implemented in the same way (in 
 terms of structure) as dynamic arrays.  I'm curious then if I declare a:

 struct z { int[] y; }

 static z[] x = [ { y:[1,2,3] } ];

 Does this implement a static array, or a dynamic array?  I *hope* a 
 dynamic one, as otherwise I will have to rewrite my entire Global_init 
 routine for Walnut 2.x.  : o

Dynamic arrays. Nothing in the brackets -- always dynamic.
 According to the D spec, that should compile as a rectangular array.  I 
 haven't tried it.  I have read the spec.

 See:
 http://digitalmars.com/d/arrays.html
 and visit "Rectangular Arrays".

quote: ================ Fortunately, D static arrays, while using the same syntax, are implemented as a fixed rectangular layout: double[3][3] matrix; declares a rectangular matrix with 3 rows and 3 columns, all contiguously in memory. ***In other languages***, this would be called a multidimensional array and be declared as: double matrix[3,3]; ================ Notice the "in other languages" bit ;) (though I have no idea _what_ other languages Walter's referring to in this sentence..)
 PS: Walter, any chance we can get <a name=""> so we can link directly to 
 specific parts of the spec?

I think there are some anchors, they're just not visible outside the page source. That would be very convenient, of course.
Apr 09 2007
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 09 Apr 2007 20:38:03 -0400, Dan wrote:

 
 Sorry, "int[5,5]" only compiles because of the obscure comma operator. 

According to the D spec, that should compile as a rectangular array. I haven't tried it. I have read the spec. See: http://digitalmars.com/d/arrays.html and visit "Rectangular Arrays".

I don't read the spec that way at all. "Fortunately, D static arrays, while using the same syntax, are implemented as a fixed rectangular layout: double[3][3] matrix; declares a rectangular matrix with 3 rows and 3 columns, all contiguously in memory. In other languages, this would be called a multidimensional array and be declared as: double matrix[3,3]; " To me, this is say that D uses the [3][3] syntax but *other* languages use the [3,3] syntax. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Justice for David Hicks!" 10/04/2007 11:03:42 AM
Apr 09 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Derek Parnell wrote:
 On Mon, 09 Apr 2007 20:38:03 -0400, Dan wrote:
 
 Sorry, "int[5,5]" only compiles because of the obscure comma operator. 

See: http://digitalmars.com/d/arrays.html and visit "Rectangular Arrays".

I don't read the spec that way at all. "Fortunately, D static arrays, while using the same syntax, are implemented as a fixed rectangular layout: double[3][3] matrix; declares a rectangular matrix with 3 rows and 3 columns, all contiguously in memory. In other languages, this would be called a multidimensional array and be declared as: double matrix[3,3]; " To me, this is say that D uses the [3][3] syntax but *other* languages use the [3,3] syntax.

Dan is not the first one to misread that particular passage in that particular way. It needs to be rewritten. The fact that the [3,3] appears in a code box just like other D code is hugely misleading. It should at least be followed by an ALL CAPS comment: double matrix[3,3]; // NOT D CODE! But anyway, there's really no reason for that last sentence. Just cut it, I say. The docs are supposed to describe what you can do in *D* and how to do it. How other (vague and unspecified) languages do it is irrelevant. --bb
Apr 09 2007
parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 10 Apr 2007 12:36:53 +0900, Bill Baxter wrote:

 But anyway, there's really no reason for that last sentence.  Just cut 
 it, I say.  The docs are supposed to describe what you can do in *D* and 
 how to do it.  How other (vague and unspecified) languages do it is 
 irrelevant.

Yep. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Justice for David Hicks!" 10/04/2007 2:38:43 PM
Apr 09 2007
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Graham wrote

 A floating point texture buffer - 3 floats per pixel, and (say)
 640x480 pixels.

To me your remark does not explain the necessity of O(1) access to an element randomly choosen---sorry for letting that out in my previous question. -manfred
Apr 08 2007
parent reply Graham <grahamamacdonald gmail.com> writes:
I'm not sure why you're concentrating on O(1) random access.  I need a 
static buffer of fixed width & height.  As I mentioned in a previous 
post, I could use a 1D array, but wanted to try a multi dimensional 
array and was puzzled why the initialiser didn't work.  I'm passing this 
array to OpenGL, so I need a contiguous buffer.

Does that explain what I'm after?

Thanks.

Manfred Nowak wrote:
 Graham wrote
 
 A floating point texture buffer - 3 floats per pixel, and (say)
 640x480 pixels.

To me your remark does not explain the necessity of O(1) access to an element randomly choosen---sorry for letting that out in my previous question. -manfred

Apr 08 2007
parent Manfred Nowak <svv1999 hotmail.com> writes:
Graham wrote

 
 Does that explain what I'm after?

Yes. Thx. I am just searching for the more general pattern. Now I can give up to find a foundation for your wish:
 I'd much rather treat it similarly to a 1D array in this case!

As you state it yourself it is just a single case, where you want to treat something differently from the general pattern, that arrays of type T[] are assigned to by mentioning a value of the type T. You want to extend this general pattern by being able for all natural numbers n to initialize an array of type T[]^n by mentioning a value of type T. But how to write a class that is able to mimic this behaviour? -manfred
Apr 08 2007
prev sibling parent reply "Craig Black" <cblack ara.com> writes:
Graham, I was wondering if you were someone that I know.  Are you the Graham 
I am thinking of?

-Craig

"Graham" <grahamamacdonald gmail.com> wrote in message 
news:ev7kdm$1p8e$1 digitalmars.com...
 Why will array setting work for a 1D array, but not a 2D?  If I enter:
   int[5] buffer;
   buffer[] = 5;

 It compiles, but if I enter:
   int[5][5] buffer;
   buffer[][] = 5;

 (I tried the variation buffer[] = 5, but that didn't work either.)

 It fails to compile (in gdc), with the warning:

   MainLoop.d:56: Error: cannot implicitly convert expression (5) of type 
 int to int[5]
   Error: cannot cast int to int[5]
   make: *** [build/MainLoop.o] Error 1

 To my untrained eye, it looks like it would like me to pass it an int[5] 
 to initialize the array, but that's a bit odd - I'd much rather treat it 
 similarly to a 1D array in this case!

 Thanks,
 graham 

Apr 09 2007
next sibling parent "Saaa" <empty needmail.com> writes:
I think you have yourself confused.
http://stumail.curry.edu/~dthibeau/Graham_Craig.jpg


 Graham, I was wondering if you were someone that I know.  Are you the 
 Graham I am thinking of?

 -Craig

Apr 09 2007
prev sibling parent Graham MacDonald <grahamamacdonald gmail.com> writes:
I don't think so...  Sorry!

Craig Black wrote:
 Graham, I was wondering if you were someone that I know.  Are you the Graham 
 I am thinking of?
 
 -Craig
 
 "Graham" <grahamamacdonald gmail.com> wrote in message 
 news:ev7kdm$1p8e$1 digitalmars.com...
 Why will array setting work for a 1D array, but not a 2D?  If I enter:
   int[5] buffer;
   buffer[] = 5;

 It compiles, but if I enter:
   int[5][5] buffer;
   buffer[][] = 5;

 (I tried the variation buffer[] = 5, but that didn't work either.)

 It fails to compile (in gdc), with the warning:

   MainLoop.d:56: Error: cannot implicitly convert expression (5) of type 
 int to int[5]
   Error: cannot cast int to int[5]
   make: *** [build/MainLoop.o] Error 1

 To my untrained eye, it looks like it would like me to pass it an int[5] 
 to initialize the array, but that's a bit odd - I'd much rather treat it 
 similarly to a 1D array in this case!

 Thanks,
 graham 


Apr 11 2007