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 (15/55) Apr 30 2004 maintains
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.
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>
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.
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.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. 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/
Apr 29 2004
"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/
Apr 29 2004
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
"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
"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...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> MatthewIf 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...
Apr 29 2004
"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...one"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 maintainstheI'm not sure about their being built in, but I believe that there should certainly be adequate support in terms of operator overloading such thatlinear 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...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 explainshowit's possible to get about 98% of the way to a natural integration withthelanguage, but that 2% is not possible and pretty tricksy<shameless plug> Matthew
Apr 29 2004
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/
Apr 30 2004
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message news:c6svq5$1a8p$1 digitaldaemon.com...Ivan Senji wrote:I could live with this. But this is probbably impossible to parse.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/
Apr 30 2004
Ivan Senji wrote: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. -- andyI 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.
Apr 30 2004
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
"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...I don't suggest that at all."Ivan Senji" <ivan.senji public.srce.hr> wrote in message news:c6rrks$2kk2$1 digitaldaemon.com...one"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 maintainstheI'm not sure about their being built in, but I believe that there should certainly be adequate support in terms of operator overloading such thatlinear 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...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!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
"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...maintains"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: itshouldoneI'm not sure about their being built in, but I believe that therelinear 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...thatcertainly be adequate support in terms of operator overloading suchone!theI don't suggest that at all.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 secondNot an issue. I propose having classes with the necessary operatoroverloading.succesful.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 wasNot what I'm suggesting. I am suggesting that there would be classes thatwouldhave 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