Multi dimensional array question.

Tim Verweij tjverweij at gmail.com
Fri Jul 16 11:45:26 PDT 2010


On 16 July 2010 20:11, Mafi <mafi at example.org> wrote:

> Am 16.07.2010 11:12, schrieb Heywood Floyd:
>
>  Lars T. Kyllingstad Wrote:
>>
>>  I do agree that, if possible, the language should match how most people
>>> think.  But in this case, it is impossible, because of templates.  How
>>> would the following example work with T = int[3], if arrays worked the
>>> way you want?
>>>
>>>   struct MyArray(T)
>>>   {
>>>       T[] a;
>>>   }
>>>
>>> C doesn't have this issue, because it doesn't have templates.  And I'll
>>> have my templates over C-style array declarations any time, thank you. :)
>>>
>>> -Lars
>>>
>>
>>
>> Well, I suppose the obvious way is to introduce array as a proper type,
>> and not
>> just as syntactical sugar. For instance, consider:
>>
>> array[11] int myArr;
>>
> ...
>
> I don't really like it. Of course the order of indices feels better but it
> breaks the rule of reading types from right to left. It also introduces more
> parenthesis and a new keyword into types (amongst const, immutable and
> delegate etc). Consider:
>  shared array[3](const( array[5] immuttable((SList!(int)*)[]) ))
> WTF, that doesn't look good. I would be a real type if your answer was
> accepted.
>
> It was
>  shared const( immutable(Slist!(int)*[])[5] )[3]
> which reads perfectly from right to left.
>
>
So why all the extra parenthesis? Do you think they are required? Instead
of:
shared array[3](const( array[5] immutable((SList!(int)*)[]) ))
consider this:
shared array[3] const array[5] immutable array (SList!(int)*)
(or array[] instead of just array)

Actually, tbh I think they all look horrible. :-P I hope I never encounter
such an impractical beast.


> What about this:
>  // int[width,height] as sugar for int[height][width]
>  int[width,height] arr = ...;
>  // arr[x,y] as sugar for arr[x][y]
>  int element = arr[x,y];
>  // then this works as expected
>  int[height] column = arr[x];
>

That doesn't look too bad.

Groet,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20100716/e1d4ce5c/attachment-0001.html>


More information about the Digitalmars-d-learn mailing list