## D - D arrays

• Ivan Senji (46/46) Apr 29 2004 D arrays have a great potential for being very powerful.
• Ivan Senji (5/51) Apr 29 2004 D is a great language and in many aspects it made my life
• J Anderson (10/57) Apr 29 2004 I would like this also. With rectangular bigW has said that its easy
• Ivan Senji (39/47) Apr 29 2004 Ah! The good old C days!
• Ilya Minkov (5/5) Apr 29 2004 If i recall correctly, Matthew has just written a tamplate making
• Ivan Senji (7/12) Apr 29 2004 I read about it too. And i am sure it is great. But the thing that
• Matthew (11/22) Apr 29 2004 I'm not sure about their being built in, but I believe that there should
• Ivan Senji (15/38) Apr 29 2004 one
• J Anderson (8/13) Apr 30 2004 I know there are problems with the comma operator but I think the most
• Ivan Senji (3/17) Apr 30 2004 I could live with this. But this is probbably impossible to parse.
• Andy Friesen (6/13) Apr 30 2004 I could too.
• Matthew (19/32) Apr 30 2004 I find it very useful for small function bodies:
• Matthew (7/39) Apr 30 2004 I don't suggest that at all.
"Ivan Senji" <ivan.senji public.srce.hr> writes:
```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.
```
Apr 29 2004
"Ivan Senji" <ivan.senji public.srce.hr> writes:
```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.

```
Apr 29 2004
```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.

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.

--
```
Apr 29 2004
"Ivan Senji" <ivan.senji public.srce.hr> writes:
```"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!

--

```
Apr 29 2004
Ilya Minkov <minkov cs.tum.edu> writes:
```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
```
Apr 29 2004
"Ivan Senji" <ivan.senji public.srce.hr> writes:
```"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

```
Apr 29 2004
"Matthew" <matthew.hat stlsoft.dot.org> writes:
```"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
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
```
Apr 29 2004
"Ivan Senji" <ivan.senji public.srce.hr> writes:
```"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

the
mechanisms I use in the STLSoft arrays would not be necessary.

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

```
Apr 29 2004
```Ivan Senji wrote:

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.

--
```
Apr 30 2004
"Ivan Senji" <ivan.senji public.srce.hr> writes:
```"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c6svq5\$1a8p\$1 digitaldaemon.com...
Ivan Senji wrote:

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;

I could live with this. But this is probbably impossible to parse.

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

--

```
Apr 30 2004
Andy Friesen <andy ikagames.com> writes:
```Ivan Senji wrote:
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;

I could live with this. But this is probbably impossible to parse.

I could too.

As for parsing, is there any compelling argument for keeping the comma
operator?  The only place I have ever (sanely) seen it used is in for
loops, and I don't think it's particularly pretty even then.

-- andy
```
Apr 30 2004
"Matthew" <matthew.hat stlsoft.dot.org> writes:
```I find it very useful for small function bodies:

bool func(X *px)
{
return (NULL == px) ? false : (px->method(), true);
}

But I concede that that's only sugar. A more compelling need is when
initialising
const variables and class members in member initialiser lists.

class Thing
{
public:
Thing(thing_t x)
: m_member1((ThingApi_Init(), ThingApi_Alloc(x))
{}

private:
thing_t const    m_member;
};

but this is not needed in D.

"Andy Friesen" <andy ikagames.com> wrote in message
news:c6u1n2\$10v\$1 digitaldaemon.com...
Ivan Senji wrote:
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;

I could live with this. But this is probbably impossible to parse.

I could too.

As for parsing, is there any compelling argument for keeping the comma
operator?  The only place I have ever (sanely) seen it used is in for
loops, and I don't think it's particularly pretty even then.

-- andy

```
Apr 30 2004
"Matthew" <matthew.hat stlsoft.dot.org> writes:
```"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

the
mechanisms I use in the STLSoft arrays would not be necessary.

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. ;)
```
Apr 30 2004
"Ivan Senji" <ivan.senji public.srce.hr> writes:
```"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c6t0fo\$1bdt\$1 digitaldaemon.com...
"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

that
the
mechanisms I use in the STLSoft arrays would not be necessary.

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

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

So the best solution would be to provide better operator oveloading, and
add built-in rectangular arrays so they would work in a natural way.

I think there is analogy: associative arrays and map. Sometimes you need
the aditional functionallity so you use map but sometimes good old
associative array
is good enough :)
```
Apr 30 2004