www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Multi dimensional array question.

reply dcoder <gtdegamo yahoo.com> writes:
Hello.

I'm wondering why in D if you declare a fixed multi dimensional array, you
have to reverse the index order to access an element.  I know it has something
to do with how tightly [] bind, but the consequence is that it seems so
different to other languages, it makes it error prone.  So here's some code
that compiles and works:



import std.stdio;

int main() {
  int[3][5] marr;
  int i = 0;

  foreach( j, ref a; marr) {
    writefln( "%s: a.length = %s", j, a.length);
    foreach( ref v; a) {
      v = i++;
    }
  }


  /* This doesn't work.  marr[0][>=3] is out of bounds!!

     writefln( "marr[0][0] = %s", marr[0][0]);
     writefln( "marr[0][1] = %s", marr[0][1]);
     writefln( "marr[0][2] = %s", marr[0][2]);
     writefln( "marr[0][3] = %s", marr[0][3]);
     writefln( "marr[0][4] = %s", marr[0][4]);


     writefln( "marr[1][0] = %s", marr[1][0]);
     writefln( "marr[1][1] = %s", marr[1][1]);
     writefln( "marr[1][2] = %s", marr[1][2]);
     writefln( "marr[1][3] = %s", marr[1][3]);
     writefln( "marr[1][4] = %s", marr[1][4]);
  */


  writefln( "marr[0][0] = %s", marr[0][0]);
  writefln( "marr[1][0] = %s", marr[1][0]);
  writefln( "marr[2][0] = %s", marr[2][0]);
  writefln( "marr[3][0] = %s", marr[3][0]);
  writefln( "marr[4][0] = %s", marr[4][0]);
  writefln( "");

  writefln( "marr[0][1] = %s", marr[0][1]);
  writefln( "marr[1][1] = %s", marr[1][1]);
  writefln( "marr[2][1] = %s", marr[2][1]);
  writefln( "marr[3][1] = %s", marr[3][1]);
  writefln( "marr[4][1] = %s", marr[4][1]);
  writefln( "");

  writefln( "marr[0][2] = %s", marr[0][2]);
  writefln( "marr[1][2] = %s", marr[1][2]);
  writefln( "marr[2][2] = %s", marr[2][2]);
  writefln( "marr[3][2] = %s", marr[3][2]);
  writefln( "marr[4][2] = %s", marr[4][2]);
  writefln( "");

  return 0;
}


Anyways, perhaps I am doing something wrong, or I have been writing too much C
code.  What are your thoughts?
Jul 11 2010
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
dcoder <gtdegamo yahoo.com> wrote:

 I'm wondering why in D if you declare a fixed multi dimensional array,  
 you
 have to reverse the index order to access an element.  I know it has  
 something
 to do with how tightly [] bind, but the consequence is that it seems so
 different to other languages, it makes it error prone.

The idea is that T[] is an array of T, for any T. if T == int[3], T[] would be int[3][]. Also, for indexing, given T[] arr. arr[i] peels off the first layer, giving you a T. If arr[i] used the first set of brackets, generic functions would be thoroughly borked, as a T passed to a template as int[3] would lead to different indexing from a T of int. -- Simen
Jul 11 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello dcoder,

 Hello.
 
 I'm wondering why in D if you declare a fixed multi dimensional array,
 you have to reverse the index order to access an element.  

When declaring an array, the base type is getting wrapped. When using an array, the base types get unwrapped. Because both forms place the [] as a subfix and in both cases the sub-type/expression needs to be contiguous it end up the way it is. alias int[5] T T[7] aa; T a = aa[6]; int v = a[4]; or (int[5])[7] aa; int v = (aa[6])[4]; -- ... <IXOYE><
Jul 11 2010
prev sibling next sibling parent reply Heywood Floyd <soul8o8 gmail.com> writes:
This had me crazy. I ended up putting the brackets on the variable, like

  int marr[3][5];

then it worked like

  marr[2][4] = 9;
Jul 12 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Heywood Floyd:
 This had me crazy. I ended up putting the brackets on the variable, like
   int marr[3][5];
 then it worked like
   marr[2][4] = 9;

That's present only for compatibility with C syntax, this means that you can use it to perform a quicker port of C code to D, but you are supposed to later convert it to D-style array definitions. See also: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=113185 Bye, bearophile
Jul 12 2010
parent reply Heywood Floyd <soul8o8 gmail.com> writes:
bearophile Wrote:

 Heywood Floyd:
 This had me crazy. I ended up putting the brackets on the variable, like
   int marr[3][5];
 then it worked like
   marr[2][4] = 9;

That's present only for compatibility with C syntax, this means that you can use it to perform a quicker port of C code to D, but you are supposed to later convert it to D-style array definitions. See also: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=113185 Bye, bearophile

Aha, good to know! Thanks! (So this might go away in the future? Or require a -cstyle compile flag?) *** I have a feeling this "backwards"-array stuff is gonna be one of the things my brain will repel for as long as it can. To me, it seems equal to saying "you declare a function like: void foo(string name, int age){ //... } And then call it by doing foo(90,"Benny") and this makes sense because the arguments are actually pushed on the stack in reverse at runtime, so they arrive in the correct order in the function. And this is especially important with tuples." or something. Ok, I understand this has some deep purpose that I still don't understand, I'm just, yeah. *tear* (Although this is way out of my league: For instance, if a T is an int[3][4], then why can't T[string] be a int[string][3][4], and be accessed with arr["a"][2][3]? Seems just like a matter of taste?) /HF PS. I was not the thread creator. I just used the creator's terminology to "stay on topic". Maybe too on topic : ) Not important really. Sorry for the confusion. DS.
Jul 12 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Heywood Floyd:
 Aha, good to know! Thanks!
 (So this might go away in the future? Or require a -cstyle compile flag?)

It's just an idea of mine, my weight in D design is near zero, and Walter doesn't love warnings. I don't know if C-style array definitions will ever go away from D, don't hold your breath :-) But in D code I suggest to replace them with D-style array definitions when possible.
 PS. I was not the thread creator. I just used the creator's terminology to
"stay on topic". Maybe too on topic : ) Not important really. Sorry for the
confusion. DS.

I am sorry, my error :-( Bye, bearophile
Jul 12 2010
prev sibling parent reply Heywood Floyd <soul8o8 gmail.com> writes:
Lars T. Kyllingstad Wrote:

 
 But then arrays would be different from all other types!  If you have an 
 array of 3 Ts, that is written T[3], regardless of what T is.  Now 
 consider these two cases:
 
    A. T is an int.  Then T[3] becomes int[3].
 
    B. T is an int[string].  Then T[3] becomes int[string][3].
 
 In case A, the first element of the array is accessed like this:
 
    int[3] a;
    int firstA = a[0];
 
 Since a is an array of int, firstA is of course an int.
 
 But then, since b is an array of int[string], we have
 
    int[string][3] b;
    int[string] firstB = b[0];
 
 If we again want to access element "foo" of the associative array which 
 is firstB, we write firstB["foo"].  And so we have the following three 
 ways to get to that element, which *must* be equivalent because that's 
 how the language is defined:
 
    // Using firstB as an intermediate step
    int[string] firstB = b[0];
    int x = firstB["foo"];
 
    // Drop the intermediate variable firstB
    int x = (b[0])["foo"];
 
    // Drop the redundant parentheses
    int x = b[0]["foo"];
 
 So you see, it can't be any other way than the way it is. :)
 
 -Lars

Thank you for the elaborate answer! When you put it like that, it does make sense. But I'm sorry. I refuse. The reason I refuse is those examples are void of any higher semantic meaning. Once we add a semantic meaning, it simply becomes backwards: int[MAX_WIDTH][MAX_HEIGHT] map2d; map2d[x][y] = 9; // Wrong! At least in my head, this is cognitive dissonance. To me, the language acts as if it's low-level semantics outweighs my high-level semantics and I should correct my thinking for that. I refuse! Seems to me it could just as well work as: int[string][3] b; int[3] firstB = b["foo"]; int i = firstB[0]; int j = (b["foo"])[0]; int k = b["foo"][0]; But I feel like I'm the only one feeling this, so I'll just let it go and hope my dear C-style arrays stay in :) BR /HF PS. Never thought I'd find a reason to love C.. DS.
Jul 14 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:
 [5](int) const a;

Go language uses something similar, and I find it a bit better than D syntax. Bye, bearophile
Jul 15 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:
 Personally, I'd advise you to just use dynamic arrays unless you do
 some profiling and find that a static array is better in a particular case.

To program you need a less naive view. I sometimes start using dynamic arrays everywhere because they are handy, then I profile code and then replace some critical allocations of dynamic arrays with static arrays, and I usually see good speed-ups. With some brain you can often find a static size (or a way to compute it statically) that is good for the algorithm/problem you are working on. In such cases using a static array is often better, the GC doesn't need to deallocate it, and heap activity is one of the most important causes of low performance in programs (or if they are allocated inside class/struct instances you remove some heap allocations, coalescing them). Static arrays are simpler, so in some situations they can make the code simpler. Bye, bearophile
Jul 15 2010
prev sibling parent reply Heywood Floyd <soul8o8 gmail.com> writes:
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; The array "wraps around" a more basic type. It's simply read from left to right. This should feel "right" for most people. Now it's easy extend this to multidimensional arrays. We just allow arrays to wrap arrays: array[3] array[11] int myArr2d; This way it's clear what's happening. It's "true" to what's going on at the compiler level. We have an "outer" array that holds 3 "inner" arrays of 11 ints. And, it's "true" to our high level semantics—when we later access the elements, the order is kept intact, as we traverse down the array stack: myArr2d[outer][inner] = 9; It's then not too far of a stretch to allow this array-keyword to accept multidimensional declarations, without reversing the order. Here, it's still quite clear what's happening: (At least if we have seen the above.) array[3][11] int myArr2d; myArr2d[0][10] = 9; //ok When we introduce templates, this should still work: struct MyArray(T){ array[3] T a; } // Let's try T == array[11] int array[3] T a; array[3] (array[11] int) a; array[3] array[11] a; array[3][11] a; a[0][10] = 9; //ok This makes a lot more sense, for me anyway. It's closer to what's actually happening, and it doesn't reverse things at a higher level. BR /HF
Jul 16 2010
parent reply Mafi <mafi example.org> writes:
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. 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];
Jul 16 2010
parent reply Heywood Floyd <soul8o8 gmail.com> writes:
Mafi Wrote:

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

Interesting! First of all, I definitely think that how arrays are declared now would have to stay just the way it is, no matter what. I don't think stuff like that is changeable this late in a language. But, seems to me these two methods of declaring arrays could coexist. One is the shorter syntactical "sugar" method, the other is the elaborate, but perhaps clearer method. These kinds of long way/shortcuts are already in the language, I believe. Like how void()() is automatically a template, comes to mind. (Or did that make sense?) Then, I simply can't resist commenting this exceptional beauty. I'm gonna call it theThing: shared const( immutable(Slist!(int)*[])[5] )[3] theThing; Well. I have to confess, to me, it doesn't read perfectly from right to left. I might be reading it wrong, but to me it reads from right to left, and from left to right, at the same time. Is it a shared const array of something, or a shared array of const something? You can't really tell unless you go back and forth, and almost count the parenthesis. For instance, by looking at the declaration above, what type is a theThing[0][1] ::= ?? It's really not easy to say, for me anyway. I'm sure you get better at reading these things. So it might not be fair to say that it's "unclear". It's just my subjective opinion, and that may be biased by my lack of experience in the matter. Now back to the other thing: shared array[3] const array[5] immutable array[] (SList!(int)*) Sure, this is too verbose. I agree. Still, I think it's clearer. Much clearer. Verbose, but clear. Here I couldn't help but making an interesting obvservation: Those storage classes could also be seen as types. What if we allowed the storage classes to have some syntactical sugar too, for arrays? We could have: shared[3] const[5] immutable[] SList!(int)* theThing; That does read from left to right in one go, and to me, it's still clear what's going on, and, it's not verbose. In fact, it's less verbose than the parenthesis-sprinkled version we saw first. Further, it's almost magically easy to read: We have a shared array of 3 const arrays of 5 immutable dynamic arrays of Slist!(int)*. It just reads, like you read text, quite naturally. (I'm not sure this would actually be the same type as the first declaration, erh, but yes. You get my intention.) So again, what type is a theThing[0][1] ::= ?? Well, if we look at the declaration above it's quite easy: We just cut the line after the second array, const[5], and the rest of the line, that's our type. theThing[0][1] ::= immutable[] SList!(int)* Now, to me, that's just plain beautiful. *** And last, the int[x,y] arr; I like it. Simple. Nice. Maybe it becomes weird when we have mixed array types, like int[uint,,5] arr? Well at least the illusion of an intact order is maintained. BR /HF
Jul 16 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Heywood Floyd:
 First of all, I definitely think that how arrays are declared now would have
to stay just the way it is,
 no matter what. I don't think stuff like that is changeable this late in a
language.

Recently I have suggested to remove the syntax: new int[20]; And allow only: new int[](20);
    shared array[3] const array[5] immutable array[] (SList!(int)*)
 
 Sure, this is too verbose. I agree. Still, I think it's clearer. Much clearer.
Verbose, but clear.

I don't know how you can write that in a Go-language-like syntax, maybe it's a bit worse.
 And last, the
    int[x,y] arr;
 
 I like it. Simple. Nice. 

It's nice, but unfortunately the comma syntax is present in C too, where: int[10] arr; int element = arr[x, y]; Equals to: int[10] arr; int element = arr[y]; So in D the usage of comma inside [] was recently forbidden. Keeping some kind of backward compatibility with C is something a kind of damnation (see also switch syntax, tuple syntax, etc). Bye, bearophile
Jul 16 2010
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Mon, 12 Jul 2010 17:23:16 -0400, Heywood Floyd wrote:

 bearophile Wrote:
 
 Heywood Floyd:
 This had me crazy. I ended up putting the brackets on the variable,
 like
   int marr[3][5];
 then it worked like
   marr[2][4] = 9;

That's present only for compatibility with C syntax, this means that you can use it to perform a quicker port of C code to D, but you are supposed to later convert it to D-style array definitions. See also: http://www.digitalmars.com/webnews/newsgroups.php?


 
 Bye,
 bearophile

Aha, good to know! Thanks! (So this might go away in the future? Or require a -cstyle compile flag?) *** I have a feeling this "backwards"-array stuff is gonna be one of the things my brain will repel for as long as it can. To me, it seems equal to saying "you declare a function like: void foo(string name, int age){ //... } And then call it by doing foo(90,"Benny") and this makes sense because the arguments are actually pushed on the stack in reverse at runtime, so they arrive in the correct order in the function. And this is especially important with tuples." or something. Ok, I understand this has some deep purpose that I still don't understand, I'm just, yeah. *tear* (Although this is way out of my league: For instance, if a T is an int[3][4], then why can't T[string] be a int[string][3][4], and be accessed with arr["a"][2][3]? Seems just like a matter of taste?)

But then arrays would be different from all other types! If you have an array of 3 Ts, that is written T[3], regardless of what T is. Now consider these two cases: A. T is an int. Then T[3] becomes int[3]. B. T is an int[string]. Then T[3] becomes int[string][3]. In case A, the first element of the array is accessed like this: int[3] a; int firstA = a[0]; Since a is an array of int, firstA is of course an int. But then, since b is an array of int[string], we have int[string][3] b; int[string] firstB = b[0]; If we again want to access element "foo" of the associative array which is firstB, we write firstB["foo"]. And so we have the following three ways to get to that element, which *must* be equivalent because that's how the language is defined: // Using firstB as an intermediate step int[string] firstB = b[0]; int x = firstB["foo"]; // Drop the intermediate variable firstB int x = (b[0])["foo"]; // Drop the redundant parentheses int x = b[0]["foo"]; So you see, it can't be any other way than the way it is. :) -Lars
Jul 13 2010
parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Wednesday, July 14, 2010 13:57:13 Heywood Floyd wrote:
 
 Thank you for the elaborate answer!
 
 When you put it like that, it does make sense. But I'm sorry. I refuse. The
 reason I refuse is those examples are void of any higher semantic meaning.
 Once we add a semantic meaning, it simply becomes backwards:
 
 int[MAX_WIDTH][MAX_HEIGHT] map2d;
 map2d[x][y] = 9; // Wrong!
 
 At least in my head, this is cognitive dissonance. To me, the language acts
 as if it's low-level semantics outweighs my high-level semantics and I
 should correct my thinking for that. I refuse! Seems to me it could just
 as well work as:
 
 int[string][3] b;
 int[3] firstB = b["foo"];
 int i = firstB[0];
 int j = (b["foo"])[0];
 int k = b["foo"][0];
 
 But I feel like I'm the only one feeling this, so I'll just let it go and
 hope my dear C-style arrays stay in :)
 
 BR
 /HF
 
 PS. Never thought I'd find a reason to love C.. DS.

Personally, I don't like it, but I also don't think that it necessarily makes sense to change it. From the point of view of how the compiler deduces types, it's exactly how it should work. The problem, of course, is that it doesn't match how we think. However, in order for us to be able to deduce complicated types, the compiler must be totally consistent in how it deduces the type. A prime example would be function pointers (particularly using the C syntax). To be able to pick it apart properly, you're going to have to understand how the compiler does it. The type is complicated enough that you're stuck. To read arrays in the reverse order that is done now, you'd have to read everything else in the reverse order to be consistent, which would really mean types like this: [5](int) const a; The whole thing is ugly. There's no question of that. But to "fix" it breaks other stuff. Types are read right to left. Being consistent with that makes it possible to understand more complicated types. The downside is that some simpler types become harder to understand. However, as long as you use dynamic arrays, this really isn't a problem. int[][] a = new int[][](MAX_WIDTH, MAX_HEIGHT); is totally clear and it works in the order that you think. The problem is when you use statically-allocated arrays. Personally, I'd advise you to just use dynamic arrays unless you do some profiling and find that a static array is better in a particular case. Doing things that way makes it so that the weird ordering in declarations isn't generally a problem. I agree that this particular syntactic faux pas is a problem, but I don't think that anyone has come up with an appropriate solution. Simply reversing how it works now would make reading more complex types much harder. A more complex solution would likely be required. As it stands, it's a problem, but it's only a problem if you're declaring statically-allocated arrays. It's unpleasant, but it should be manageable. - Jonathan M Davis
Jul 14 2010
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Wed, 14 Jul 2010 16:57:13 -0400, Heywood Floyd wrote:

 Lars T. Kyllingstad Wrote:
 
 
 But then arrays would be different from all other types!  If you have
 an array of 3 Ts, that is written T[3], regardless of what T is.  Now
 consider these two cases:
 
    A. T is an int.  Then T[3] becomes int[3].
 
    B. T is an int[string].  Then T[3] becomes int[string][3].
 
 In case A, the first element of the array is accessed like this:
 
    int[3] a;
    int firstA = a[0];
 
 Since a is an array of int, firstA is of course an int.
 
 But then, since b is an array of int[string], we have
 
    int[string][3] b;
    int[string] firstB = b[0];
 
 If we again want to access element "foo" of the associative array which
 is firstB, we write firstB["foo"].  And so we have the following three
 ways to get to that element, which *must* be equivalent because that's
 how the language is defined:
 
    // Using firstB as an intermediate step int[string] firstB = b[0];
    int x = firstB["foo"];
 
    // Drop the intermediate variable firstB int x = (b[0])["foo"];
 
    // Drop the redundant parentheses
    int x = b[0]["foo"];
 
 So you see, it can't be any other way than the way it is. :)
 
 -Lars

Thank you for the elaborate answer! When you put it like that, it does make sense. But I'm sorry. I refuse. The reason I refuse is those examples are void of any higher semantic meaning. Once we add a semantic meaning, it simply becomes backwards: int[MAX_WIDTH][MAX_HEIGHT] map2d; map2d[x][y] = 9; // Wrong! At least in my head, this is cognitive dissonance. To me, the language acts as if it's low-level semantics outweighs my high-level semantics and I should correct my thinking for that. I refuse! Seems to me it could just as well work as: int[string][3] b; int[3] firstB = b["foo"]; int i = firstB[0]; int j = (b["foo"])[0]; int k = b["foo"][0]; But I feel like I'm the only one feeling this, so I'll just let it go and hope my dear C-style arrays stay in :) BR /HF PS. Never thought I'd find a reason to love C.. DS.

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
Jul 15 2010
prev sibling next sibling parent Tim Verweij <tjverweij gmail.com> writes:
--001485e8cefc8a1032048b7fc667
Content-Type: text/plain; charset=ISO-8859-1

On 16 July 2010 11:12, Heywood Floyd <soul8o8 gmail.com> wrote:

 Lars T. Kyllingstad Wrote:
 (...)

 When we introduce templates, this should still work:

 struct MyArray(T){
   array[3] T a;
 }

 // Let's try
 T == array[11] int

 array[3] T a;
 array[3] (array[11] int) a;
 array[3] array[11] a;
 array[3][11] a;

 a[0][10] = 9; //ok

The 'int' goes missing there. I guess you meant to write: array[3] T a; array[3] (array[11] int) a; array[3] array[11] int a; array[3][11] int a; Right? Pretty nice. I must say that I quite like this. It does feel 'right'. Groet, Tim --001485e8cefc8a1032048b7fc667 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 16 July 2010 11:12, Heywood Floyd <span dir= =3D"ltr">&lt;<a href=3D"mailto:soul8o8 gmail.com">soul8o8 gmail.com</a>&gt;= </span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0p= t 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"=

<br> When we introduce templates, this should still work:<br> <br> struct MyArray(T){<br> =A0 array[3] T a;<br> }<br> <br> // Let&#39;s try<br> T =3D=3D array[11] int<br> <br> array[3] T a;<br> array[3] (array[11] int) a;<br> array[3] array[11] a;<br> array[3][11] a;<br> <br> a[0][10] =3D 9; //ok<br></blockquote><div><br>The &#39;int&#39; goes missin= g there. I guess you meant to write:<br><br>array[3] T a;<br> array[3] (array[11] int) a;<br> array[3] array[11] int a;<br> array[3][11] int a;<br><br>Right? Pretty nice. I must say that I quite like= this. It does feel &#39;right&#39;.<br><br>Groet,<br>Tim<br><br></div></di= v> --001485e8cefc8a1032048b7fc667--
Jul 16 2010
prev sibling parent Tim Verweij <tjverweij gmail.com> writes:
--001636920ddb576cdf048b859fce
Content-Type: text/plain; charset=ISO-8859-1

On 16 July 2010 20:11, Mafi <mafi 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.

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 --001636920ddb576cdf048b859fce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 16 July 2010 20:11, Mafi <span dir=3D"ltr">&l= t;<a href=3D"mailto:mafi example.org">mafi example.org</a>&gt;</span> wrote= :<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; = border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Am 16.07.2010 11:12, schrieb Heywood Floyd:<div class=3D"im"><br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Lars T. Kyllingstad Wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I do agree that, if possible, the language should match how most people<br> think. =A0But in this case, it is impossible, because of templates. =A0How<= br> would the following example work with T =3D int[3], if arrays worked the<br=

<br> =A0 struct MyArray(T)<br> =A0 {<br> =A0 =A0 =A0 T[] a;<br> =A0 }<br> <br> C doesn&#39;t have this issue, because it doesn&#39;t have templates. =A0An= d I&#39;ll<br> have my templates over C-style array declarations any time, thank you. :)<b= r> <br> -Lars<br> </blockquote> <br> <br> Well, I suppose the obvious way is to introduce array as a proper type, and= not<br> just as syntactical sugar. For instance, consider:<br> <br> array[11] int myArr;<br> </blockquote></div> ...<br> <br> I don&#39;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 an= d delegate etc). Consider:<br> =A0shared array[3](const( array[5] immuttable((SList!(int)*)[]) ))<br> WTF, that doesn&#39;t look good. I would be a real type if your answer was = accepted.<br> <br> It was<br> =A0shared const( immutable(Slist!(int)*[])[5] )[3]<br> which reads perfectly from right to left.<br> <br></blockquote><div><br>So why all the extra parenthesis? Do you think th= ey are required? Instead of:<br>shared array[3](const( array[5] immutable((= SList!(int)*)[]) ))<br>consider this:<br>shared array[3] const array[5] imm= utable array (SList!(int)*)<br> (or array[] instead of just array)<br><br></div><div>Actually, tbh I think = they all look horrible. :-P I hope I never encounter such an impractical be= ast.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt= 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> What about this:<br> =A0// int[width,height] as sugar for int[height][width]<br> =A0int[width,height] arr =3D ...;<br> =A0// arr[x,y] as sugar for arr[x][y]<br> =A0int element =3D arr[x,y];<br> =A0// then this works as expected<br> =A0int[height] column =3D arr[x];<br> </blockquote></div><br>That doesn&#39;t look too bad.<br><br>Groet,<br>Tim<= br> --001636920ddb576cdf048b859fce--
Jul 16 2010
prev sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Thursday 15 July 2010 22:20:17 bearophile wrote:
 Jonathan M Davis:
 Personally, I'd advise you to just use dynamic arrays unless you do
 some profiling and find that a static array is better in a particular
 case.

To program you need a less naive view. I sometimes start using dynamic arrays everywhere because they are handy, then I profile code and then replace some critical allocations of dynamic arrays with static arrays, and I usually see good speed-ups. With some brain you can often find a static size (or a way to compute it statically) that is good for the algorithm/problem you are working on. In such cases using a static array is often better, the GC doesn't need to deallocate it, and heap activity is one of the most important causes of low performance in programs (or if they are allocated inside class/struct instances you remove some heap allocations, coalescing them). Static arrays are simpler, so in some situations they can make the code simpler. Bye, bearophile

Well, like I said: Use dynamic arrays unless profiling shows that static arrays would be better in a particular situation. If you really expect a section of code to need it, then it makes sense to use a static array up front. But for the most part, dynamic arrays should be fine, and personally, I find them easier to use since you have less to worry about when dealing with them. However, it's certainly true that sections critical to efficiency may require static arrays, and there's nothing wrong with choosing static arrays in either case. But I see no reason to use static arrays normally unless profiling shows that it would be of benefit. Most of the programs that I do for my own use probably wouldn't care either way. If I were using D at work (efficiency matters a lot more with what I do there), it might be different. But regardless, I wouldn't generally use static arrays unless it were clear that they were necessary. If anything though, I'm likely to be switch to use Array more now that we have it. - Jonathan M Davis
Jul 15 2010