I say that arrays should have the []'s at the end of the name. Just like
functions. You see, what I see in the C/C++ languages is that the return or
data type is at the begiining while any "grouping" symbols are at the end.
For Example,
in C/C++,
int myarray[]; // The array identifier at end
int myfunc(); // Parens denoting a function
Don't get me wrong, I KNOW that you are supposed to have it at the end
during normal use.
Also, [][]?
Why not seperate the dimensions with commas? IE,
int my_array[56,23]; /*56*23 array */
just like in functions? You dont see
int my_func(6)("3ghfogho");
do you?
I figure that the co-ordinates are essentialy parameters.
You see, you can also use an array as a function! (Though limited, but
follow along)
Let's say I want a function to compare a variable, foo to a constant qux. It
returns 1 if it's higher and 0 if it's lower.
Let's look at this in the ways I've described above:
int qux = 10;
int comparefoo(int foo)
{
if (foo<qux)
return 1;
else(foo=>qux)
return 0;
}
Now, as an array:
int myarray[1] = {0,1};
Yes, I know, the above wasn't proper D (I still think Mars is cooler) but
still. You get my point?

I say that arrays should have the []'s at the end of the name. Just like
functions. You see, what I see in the C/C++ languages is that the return

data type is at the begiining while any "grouping" symbols are at the end.
For Example,
in C/C++,
int myarray[]; // The array identifier at end
int myfunc(); // Parens denoting a function

D allows for that (although It's not mandatory).

Don't get me wrong, I KNOW that you are supposed to have it at the end
during normal use.
Also, [][]?
Why not seperate the dimensions with commas? IE,
int my_array[56,23]; /*56*23 array */

That's a good idea.

just like in functions? You dont see
int my_func(6)("3ghfogho");
do you?
I figure that the co-ordinates are essentialy parameters.
You see, you can also use an array as a function! (Though limited, but
follow along)
Let's say I want a function to compare a variable, foo to a constant qux.

I say that arrays should have the []'s at the end of the name. Just like
functions. You see, what I see in the C/C++ languages is that the return
or data type is at the begiining while any "grouping" symbols are at the
end.
For Example,
in C/C++,
int myarray[]; // The array identifier at end
int myfunc(); // Parens denoting a function

You can do this in D - int[] myArray; is not a mandatory format, although I
personally find it easier to read (given the choice though I would rather
have 'myArray int[];' [as this makes searching long lists of variable
declarations easier] - but no language is perfect).
At least the D format is consistant if you read it right ...
int[] myArray; // accessing myArray returns int[]
int myFunc() ... // accessing myFunc returns int
int[] myFunc2() ... // accessing myFunc2 returns int[]

Don't get me wrong, I KNOW that you are supposed to have it at the end
during normal use.
Also, [][]?
Why not seperate the dimensions with commas? IE,

[][] is used to designate a ragged array.
[,] could be implemented for rectangular arrays.
so.
int[4][7] array1; // is 4 ptrs to arrays of int length 7 named
array1
// (accesses required at least 1 pointer dereference)
int[4,7] array2; // is array of width 4, length 7 named array2
// (accesses do not require a pointer dereference -
// but do required a multiply / shift and add - though
// these may be optimised away some times)
If the latter is not currently supported I believe it soon should be (v2?).
Also remember we could say
x = array1[2].length;
How would we do this with your syntax array in a consistant way?
x = myarray.length[2]; // only (nice) way I can think of (==7)
x = myarray.length; // this would return 4 = 1st parameter
// other wise we just have to be inconsistant
For a rectangular array the dimensions are fixed on initialisation so we
could use
x = array2.dimension[0]; // return length == 4
x = array2.dimension[1]; // return width == 7
x = array2.dimension(1); // alt syntax - function style (?)
x = array2.length; // error "rectangular array - not
ragged array"
// (or may return length * witdh == 4*7 == 28)
Also this would allow us to do
int[5][6,7] array3; // ragged array of rectangular arrays
(though this probably should not be allowed without further investigation :
? is it useful
? is it a pain to implement (probably)
? could it lead to errors
? do the implementation costs out weight the benifits
)

int my_array[56,23]; /*56*23 array */
just like in functions? You dont see
int my_func(6)("3ghfogho");
do you?
I figure that the co-ordinates are essentialy parameters.
You see, you can also use an array as a function! (Though limited, but
follow along)
Let's say I want a function to compare a variable, foo to a constant qux.
It returns 1 if it's higher and 0 if it's lower.
Let's look at this in the ways I've described above:
int qux = 10;
int comparefoo(int foo)
{
if (foo<qux)
return 1;
else(foo=>qux)

why is the second condition needed on the else?
should this be >= not => anyway?
and why bother with the else at all in this example?

[][] is used to designate a ragged array.
[,] could be implemented for rectangular arrays.
so.
int[4][7] array1; // is 4 ptrs to arrays of int length 7

// (accesses required at least 1 pointer

int[4,7] array2; // is array of width 4, length 7 named

// (accesses do not require a pointer

// but do required a multiply / shift and add -

// these may be optimised away some times)

But then the only difference is that the [][] arrays are created by pointers and
that the [,] are now just arrays that has data that is closer together! Now
there is no point! It's like the difference between a struct and a class for
god's sake!

On Tue=2C 23 Jul 2002 18=3A27=3A12 +0000 =28UTC=29 andrew n
=3Candrew=5Fmember=40pathlink=2Ecom=3E
wrote=3A
=3E In article =3Cahj122$k31$1=40digitaldaemon=2Ecom=3E=2C Sandor Hojtsy
says=2E=2E=2E
=3E But then the only difference is that the =5B=5D=5B=5D arrays are created by
pointers
and
=3E that the =5B=2C=5D are now just arrays that has data that is closer
together! Now
There IS a difference=2E =5B=2C=5D array is =5Fguaranteed=5F to be rectangle
=28that is=2C each
row has the same size=29=2E There is no such guarantee for =5B=5D=5B=5D
arrays=2E So these are
two =5Ffundamentally=5F different data types=2E
Also=2C =5B=2C=5D arrays can be converted from static to dynamic and vice versa
easily=2E
This is not true for =5B=5D=5B=5D arrays=2E For example=2C try the following=3A
=09void calc=28double=5B=5D=5B=5D matrix=29=09
=09{
=09=09=2F=2F do something inside
=09}
=09double=5B3=5D=5B3=5D matrix=3B
=09calc=28matrix=29=3B
It won't work=2C for obvious reasons=2E And =5B=2C=5D arrays don't have such
problem=2E

that the [,] are now just arrays that has data that is closer together!

there is no point! It's like the difference between a struct and a class

god's sake!

Sometimes you need the data to be contiguous in memory,
such as with screen buffers. The ragged arrays cannot be
used then. The normal solution is to use a 1d array or
a pointer, and calculate the index or offset yourself:
int[1024*768] screen;
void drawPixel (in int x, in int y, in int color)
{
int index = y * 1024 + x;
screen[index] = color;
}
It would be cool if D could provide syntax sugar for
this kind of thing, because it is quitte common.
--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

Sometimes you need the data to be contiguous in memory,
such as with screen buffers. The ragged arrays cannot be
used then. The normal solution is to use a 1d array or
a pointer, and calculate the index or offset yourself:
int[1024*768] screen;
void drawPixel (in int x, in int y, in int color)
{
int index = y * 1024 + x;
screen[index] = color;
}
It would be cool if D could provide syntax sugar for
this kind of thing, because it is quitte common.

On Fri=2C 19 Jul 2002 22=3A14=3A57 -0700 =22Andrew Nguyen=22
=3Cpythonnet=40hotmail=2Ecom=3E
wrote=3A
=3E Also=2C =5B=5D=5B=5D=3F
=3E Why not seperate the dimensions with commas=3F IE=2C
=3E
=3E int my=5Farray=5B56=2C23=5D=3B =2F*56*23 array *=2F
It makes more sense when applied to dynamic arrays=2E So=2C we could
have two distinct types=2C one for arrays of arrays - =5B=5D=5B=5D - and
another for rectangular arrays - =5B=2C=5D=2E Just like C#=2E
=09short=5B=2C=5D screenbuf=3B
=09if =28vidmode =3D=3D VGA50=29
=09=09screen =3D new short=5B80=2C 50=5D=3B
=09else
=09=09screen =3D new short=5B80=2C 25=5D=3B
I don't know a way to do it in D=2C currently=2E You can use =5B=5D=5B=5D=2C
but then the array won't be stored as a single block in memory=2C
and thus cannot be copied easily=2E On other hand=2C rectangular
arrays could be copied=3A
=09short=5B80=2C25=5D* screen =3D cast=28short=5B80=2C25=5D*=29 0xA0000=3B
=09=28*screen=29=5B=5D =3D screenbuf=5B=5D=3B

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374577734276852 news.digitalmars.com...
It makes more sense when applied to dynamic arrays. So, we could
have two distinct types, one for arrays of arrays - [][] - and
another for rectangular arrays - [,]. Just like C#.
D already supports rectangular arrays - just supply a dimension in the
brackets. No need for a separate syntax.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374577734276852 news.digitalmars.com...
It makes more sense when applied to dynamic arrays. So, we could
have two distinct types, one for arrays of arrays - [][] - and
another for rectangular arrays - [,]. Just like C#.
D already supports rectangular arrays - just supply a dimension in the
brackets. No need for a separate syntax.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374577734276852 news.digitalmars.com...
It makes more sense when applied to dynamic arrays. So, we could
have two distinct types, one for arrays of arrays - [][] - and
another for rectangular arrays - [,]. Just like C#.
D already supports rectangular arrays - just supply a dimension in the
brackets. No need for a separate syntax.

Sorry for the repost, my finger slipped :)
But... couldn't ragged arrays SAVE memory? Like in a string array or something
of that sort.