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

> 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

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

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

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

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

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 

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/

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.
>>> 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
> 

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

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.
>>>> 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
>>
> 
> 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/