D arrays have a great potential for being very powerful.
We have dynamic arrays, associative arrays, slicing,
one day array operations but there are big problems.

1. No array litterals.
I'll demonstrate the promplem with a peace of my code:
I nead to create a matrix, i have:
////
static float[4][4] idn = [[1,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]];

Mat!(4) M1(idn); //makes an internal copy
M1.set(0,0,4);
M1.set(1,0,4);
...
///
to set every element that is different from the identity matrix.

What I would like to write is:
///
Mat!(4) M1(  [[1,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]] );
///
This code is more readable, and my matrix class constructor
wouldn't have to create a copy of the array but only save a
reference to it.

2. no new for arrays.
Many people on this newsgroup said this but i also have to.
The D way is: new is for instantiating objects, and this is something
i agree with. But arrays should also be considered objects.

Maybe D should look into how c# does this. I think there are two types of array: jagged [][]... and rectangular [,,] and the can all be created dynamically with new.

Many new D users will come to problems with arrays in D
(as I have) and will be surprised of how many things you can't
do.
They wil try:
int[] x = [2,3,5,7]; //doesnt work inside a function.
int[][] x = new int[x][y] //x,y are dynamic values.
You can allways do:

x.length = x;
for(int i=0;i<x.length; i++)
{
    x[i].length = y;
}

but this is too much code for a simple thing to do!
And this creates a jagged array, but what if i want a
rectangular one? There is no cure.

D arrays need some work, and please don't get me wrong
and think i am a D-hater, or the enemy of D, i'm a big
D's fan, and a little worried of the lack of some features.

D is a great language and in many aspects it made my life much easier, but it can get frustrating and make your life a living hell when you try to overcome some (rear) flaws :)

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:c6qgjn$h5g$1@digitaldaemon.com...
> D arrays have a great potential for being very powerful.
> We have dynamic arrays, associative arrays, slicing,
> one day array operations but there are big problems.
>
> 1. No array litterals.
> I'll demonstrate the promplem with a peace of my code:
> I nead to create a matrix, i have:
> ////
> static float[4][4] idn = [[1,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]];
>
> Mat!(4) M1(idn); //makes an internal copy
> M1.set(0,0,4);
> M1.set(1,0,4);
> ...
> ///
> to set every element that is different from the identity matrix.
>
> What I would like to write is:
> ///
> Mat!(4) M1(  [[1,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]] );
> ///
> This code is more readable, and my matrix class constructor
> wouldn't have to create a copy of the array but only save a
> reference to it.
>
> 2. no new for arrays.
> Many people on this newsgroup said this but i also have to.
> The D way is: new is for instantiating objects, and this is something
> i agree with. But arrays should also be considered objects.
>
> Maybe D should look into how c# does this. I think there are two types of array: jagged [][]... and rectangular [,,] and the can all be created dynamically with new.
>
> Many new D users will come to problems with arrays in D
> (as I have) and will be surprised of how many things you can't
> do.
> They wil try:
> int[] x = [2,3,5,7]; //doesnt work inside a function.
> int[][] x = new int[x][y] //x,y are dynamic values.
> You can allways do:
>
> x.length = x;
> for(int i=0;i<x.length; i++)
> {
>     x[i].length = y;
> }
>
> but this is too much code for a simple thing to do!
> And this creates a jagged array, but what if i want a
> rectangular one? There is no cure.
>
> D arrays need some work, and please don't get me wrong
> and think i am a D-hater, or the enemy of D, i'm a big
> D's fan, and a little worried of the lack of some features.
>
>
>
>
>
>

Ivan Senji wrote:

>D arrays have a great potential for being very powerful.
>We have dynamic arrays, associative arrays, slicing,
>one day array operations but there are big problems.
>
>1. No array litterals.
>I'll demonstrate the promplem with a peace of my code:
>I nead to create a matrix, i have:
>////
>static float[4][4] idn = [[1,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]];
>
>Mat!(4) M1(idn); //makes an internal copy
>M1.set(0,0,4);
>M1.set(1,0,4);
>...
>///
>to set every element that is different from the identity matrix.
>
>What I would like to write is:
>///
>Mat!(4) M1(  [[1,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]] );
>///
>This code is more readable, and my matrix class constructor
>wouldn't have to create a copy of the array but only save a
>reference to it.
>  
>
Yes please (this has been asked for before ).

>2. no new for arrays.
>Many people on this newsgroup said this but i also have to.
>The D way is: new is for instantiating objects, and this is something
>i agree with. But arrays should also be considered objects.
>
>Maybe D should look into how c# does this. I think there
>are two types of array: jagged [][]... and rectangular [,,]
>and the can all be created dynamically with new.
>
>Many new D users will come to problems with arrays in D
>(as I have) and will be surprised of how many things you can't
>do.
>They wil try:
>int[] x = [2,3,5,7]; //doesnt work inside a function.
>int[][] x = new int[x][y] //x,y are dynamic values.
>You can allways do:
>
>x.length = x;
>for(int i=0;i<x.length; i++)
>{
>    x[i].length = y;
>}
>
>but this is too much code for a simple thing to do!
>And this creates a jagged array, but what if i want a
>rectangular one? There is no cure.
>
>D arrays need some work, and please don't get me wrong
>and think i am a D-hater, or the enemy of D, i'm a big
>D's fan, and a little worried of the lack of some features.
>

I would like this also.  With rectangular bigW has said that its easy enough to create them using [x + y*width], so I doubt he will be putting them in.

I think with arrays you should be able to do, mostly what you expect to do. It just makes plain sense.  If D get arrays right, D would have such an edge over every language I know.

-- 
-Anderson: http://badmama.com.au/~anderson/

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c6qi6q$jjk$1@digitaldaemon.com...
> I would like this also.  With rectangular bigW has said that its easy enough to create them using [x + y*width], so I doubt he will be putting them in.

Ah! The good old C days!
Although i think bigW is a genious i couldn't disagree with him more on this
subject: To ilustrate this just one example:

version(DArray)
{
 GLubyte[3][XRES][YRES] image;
}
else
{
 GLubyte[3*YRES*XRES] image;
}

void setpixel(int x, int y,ubyte r, ubyte g, ubyte b)
{
 version(DArray)
 {
  image[y][x][0]=r;
  image[y][x][1]=g;
  image[y][x][2]=b;
 }
 else
 {
  image[x*3+y*XRES*3]=r;
  image[x*3+y*XRES*3+1]=g;
  image[x*3+y*XRES*3+2]=b;
 }
}

So wich version of setpixel is more understandable, for the second one i had to do some drawing on the paper to figure out how to do it!

I was just wondering what if there is not enough memory for "GLubyte[3][XRES][YRES] image" what happens then? My program crashes without an explanation.

If we could do something like
GLubyte[;;] image = new GLubyte[3;XRES;YRES];
and then to test if image is null or wrap it in a try block and catch an
exception we could report an error message about there not being enough
memory.

>
> I think with arrays you should be able to do, mostly what you expect to do. It just makes plain sense.  If D get arrays right, D would have such an edge over every language I know.
>

I agree!

> --
> -Anderson: http://badmama.com.au/~anderson/

If i recall correctly, Matthew has just written a tamplate making dynamic solid ("rectangular") arrays. It is very easy: it maintains one linear array of type, and computes and returns slices of it. It is really not coming close to any C solution by elegance.

-eye

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c6robh$2f7q$1@digitaldaemon.com...
> If i recall correctly, Matthew has just written a tamplate making dynamic solid ("rectangular") arrays. It is very easy: it maintains one linear array of type, and computes and returns slices of it. It is really not coming close to any C solution by elegance.

I read about it too. And i am sure it is great. But the thing that
is troubling me is the question: what are/should be basic types?
We have associative arrays in D but they are far less "basic" type
then rectangular arrays, so why not true support for them?
By true support i mean for example creating them dynamically...

>
> -eye

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:c6rrks$2kk2$1@digitaldaemon.com...
> "Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c6robh$2f7q$1@digitaldaemon.com...
> > If i recall correctly, Matthew has just written a tamplate making dynamic solid ("rectangular") arrays. It is very easy: it maintains one linear array of type, and computes and returns slices of it. It is really not coming close to any C solution by elegance.
>
> I read about it too. And i am sure it is great. But the thing that
> is troubling me is the question: what are/should be basic types?
> We have associative arrays in D but they are far less "basic" type
> then rectangular arrays, so why not true support for them?
> By true support i mean for example creating them dynamically...

I'm not sure about their being built in, but I believe that there should certainly be adequate support in terms of operator overloading such that the mechanisms I use in the STLSoft arrays would not be necessary.

<shameless plug>btw, for anyone interested, there's a big chapter on Multidimensional Arrays in "Imperfect C++" - which should be out in around September - covering a great many issues and idiosyncrasies, and explains how it's possible to get about 98% of the way to a natural integration with the language, but that 2% is not possible and pretty tricksy<shameless plug>

Matthew

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c6rusd$2ph0$1@digitaldaemon.com...
>
> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:c6rrks$2kk2$1@digitaldaemon.com...
> > "Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c6robh$2f7q$1@digitaldaemon.com...
> > > If i recall correctly, Matthew has just written a tamplate making dynamic solid ("rectangular") arrays. It is very easy: it maintains
one
> > > linear array of type, and computes and returns slices of it. It is really not coming close to any C solution by elegance.
> >
> > I read about it too. And i am sure it is great. But the thing that
> > is troubling me is the question: what are/should be basic types?
> > We have associative arrays in D but they are far less "basic" type
> > then rectangular arrays, so why not true support for them?
> > By true support i mean for example creating them dynamically...
>
> I'm not sure about their being built in, but I believe that there should certainly be adequate support in terms of operator overloading such that
the
> mechanisms I use in the STLSoft arrays would not be necessary.

Better operator overloading support is something i agree with!
But i can't agree on not having rectangular arrays built-in.
Again my example:
  image[y][x][2]=b;     // or maybe image[y;x;2]
  image[x*3+y*XRES*3+2]=b;
Wich one is something you would like to write, surely not the second one!

Some people need these types a lot, and it is a big limitation to
have to know arrays size at compile time, this is often not possible,
and even if it is, there is no way to test if the allocation was succesful.

> <shameless plug>btw, for anyone interested, there's a big chapter on Multidimensional Arrays in "Imperfect C++" - which should be out in around September - covering a great many issues and idiosyncrasies, and explains
how
> it's possible to get about 98% of the way to a natural integration with
the
> language, but that 2% is not possible and pretty tricksy<shameless plug>
>
> Matthew
>
>

Ivan Senji wrote:

>Better operator overloading support is something i agree with!
>But i can't agree on not having rectangular arrays built-in.
>Again my example:
>  image[y][x][2]=b;     // or maybe image[y;x;2]
>  
>
I know there are problems with the comma operator but I think the most obvious way for a rectangular array is

image[y, x, 2] =b;

That is what someone learning the language would expect to write for a rectangular array.

-- 
-Anderson: http://badmama.com.au/~anderson/

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:c6st8r$15eh$1@digitaldaemon.com...
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c6rusd$2ph0$1@digitaldaemon.com...
> >
> > "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:c6rrks$2kk2$1@digitaldaemon.com...
> > > "Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c6robh$2f7q$1@digitaldaemon.com...
> > > > If i recall correctly, Matthew has just written a tamplate making dynamic solid ("rectangular") arrays. It is very easy: it maintains
> one
> > > > linear array of type, and computes and returns slices of it. It is really not coming close to any C solution by elegance.
> > >
> > > I read about it too. And i am sure it is great. But the thing that
> > > is troubling me is the question: what are/should be basic types?
> > > We have associative arrays in D but they are far less "basic" type
> > > then rectangular arrays, so why not true support for them?
> > > By true support i mean for example creating them dynamically...
> >
> > I'm not sure about their being built in, but I believe that there should certainly be adequate support in terms of operator overloading such that
> the
> > mechanisms I use in the STLSoft arrays would not be necessary.
>
> Better operator overloading support is something i agree with!
> But i can't agree on not having rectangular arrays built-in.
> Again my example:
>   image[y][x][2]=b;     // or maybe image[y;x;2]
>   image[x*3+y*XRES*3+2]=b;

I don't suggest that at all.

> Wich one is something you would like to write, surely not the second one!

Not an issue. I propose having classes with the necessary operator overloading.

> Some people need these types a lot, and it is a big limitation to
> have to know arrays size at compile time, this is often not possible,
> and even if it is, there is no way to test if the allocation was succesful.

Not what I'm suggesting. I am suggesting that there would be classes that would have their sizes determined at runtime, just as with stlsoft::fixed_array. However, I am starting to think that built-in is best. ;)