www.digitalmars.com         C & C++   DMDScript  

D - D arrays

reply "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.


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
next sibling parent "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.


 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
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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
parent reply "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!
 --
 -Anderson: http://badmama.com.au/~anderson/
Apr 29 2004
parent reply 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
next sibling parent reply "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
parent reply "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 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
Apr 29 2004
parent reply "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 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
Apr 29 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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
parent reply "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:

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

 --
 -Anderson: http://badmama.com.au/~anderson/
Apr 30 2004
parent reply 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
parent "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
prev sibling parent reply "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 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. ;)
Apr 30 2004
parent "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
 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. ;)
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
prev sibling parent reply Drew McCormack <drewmccormack mac.com> writes:
On 2004-04-29 22:25:26 +0200, Ilya Minkov <minkov cs.tum.edu> said:

 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
Is this available somewhere? I was playing with the idea myself, but if someone has already done it... Drew McCormack
Apr 30 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
http://stlsoft.org/download.html - get the latest beta. The files are
stlsoft_fixed_array.h and stlsoft_frame_array.h. These have been recently
upgraded for speed and kick the pants of Boost's multi_array (which they did
before, actually, just more so now).


"Drew McCormack" <drewmccormack mac.com> wrote in message
news:c6t695$1jcd$1 digitaldaemon.com...
 On 2004-04-29 22:25:26 +0200, Ilya Minkov <minkov cs.tum.edu> said:

 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
Is this available somewhere? I was playing with the idea myself, but if someone has already done it... Drew McCormack
Apr 30 2004
next sibling parent "Achilleas Margaritis" <axilmar in.gr> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c6u9ng$en4$1 digitaldaemon.com...
 http://stlsoft.org/download.html - get the latest beta. The files are
 stlsoft_fixed_array.h and stlsoft_frame_array.h. These have been recently
 upgraded for speed and kick the pants of Boost's multi_array (which they
did
 before, actually, just more so now).


 "Drew McCormack" <drewmccormack mac.com> wrote in message
 news:c6t695$1jcd$1 digitaldaemon.com...
 On 2004-04-29 22:25:26 +0200, Ilya Minkov <minkov cs.tum.edu> said:

 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
Is this available somewhere? I was playing with the idea myself, but if someone has already done it... Drew McCormack
I think jagged arrays and dynamic arrays should be part of the language. It's one of those things that programmers expect to find in a language. It's basic stuff.
Apr 30 2004
prev sibling parent reply Drew McCormack <drewmccormack mac.com> writes:
On 2004-04-30 21:34:16 +0200, "Matthew" <matthew.hat stlsoft.dot.org> said:

 http://stlsoft.org/download.html - get the latest beta. The files are
 stlsoft_fixed_array.h and stlsoft_frame_array.h. These have been recently
 upgraded for speed and kick the pants of Boost's multi_array (which they did
 before, actually, just more so now).
Hi Matthew, Have you got anything written in D? Any plans to create similar D classes? Regarding the C++ versions, how do they compare to Blitz++? Do you use expression templates, or is it a straight multidimensional array setup like Boost? Lastly, in your experience, do you see any problems with writing similar classes for D? Are the templates in D powerful enough? I assume they are just as powerful or more powerful than C++, but... Drew
May 01 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Drew McCormack" <drewmccormack mac.com> wrote in message
news:c6vuok$2s0v$1 digitaldaemon.com...
 On 2004-04-30 21:34:16 +0200, "Matthew" <matthew.hat stlsoft.dot.org> said:

 http://stlsoft.org/download.html - get the latest beta. The files are
 stlsoft_fixed_array.h and stlsoft_frame_array.h. These have been recently
 upgraded for speed and kick the pants of Boost's multi_array (which they did
 before, actually, just more so now).
Hi Matthew, Have you got anything written in D?
std.windows.registry std.recls std.loader std.mmfile std.perf (not out yet) I've also done several tools which may be included with Phobos as samples when I get the time to present them to big-W.
 Any plans to create similar D classes?
Yes, I'm writing the DTL (D Template Library), a library of template containers, interfaces, algorithms and mixins, which will support enumeration by foreach, iterators and user-customisable interfaces (a la Java, .NET), as well as ranges via mixins (all described in detail in other threads). Unless someone else works on one, it stands a reasonable chance of becoming the D standard container/algorithm library, unless someone else beats me to it. The current status is that it's waiting for fixes and enhancements to the compiler (and the language), which Walter is working on at the moment.
 Regarding the C++ versions, how do they compare to Blitz++?
Don't know. I'd be interested to find out. Do you want to do some comparative tests? That'd be great. I won't be too upset of Blitz is better. It's dedicated to scientific stuff, is it not, whereas STLSoft is more general purpose.
 Do you use
 expression templates, or is it a straight multidimensional array setup
 like Boost?
It's an even more straightforward array setup than Boost's, hence the performance advantage. (It also works with a lot more compilers.)
 Lastly, in your experience, do you see any problems with writing
 similar classes for D?
Some, but I believe they can all be ironed out.
 Are the templates in D powerful enough?
I think the answer is probably yes. But we all have to make the adjustments to lack of implicit instantiation, etc. It just requires a different way of looking at the problems. A good example is the DTL. My C++ brain told me that iterators were the way to go, but with D's fundamental enumeration construct being foreach, it has transpired that adaptation of containers via mixins based on the container's opApply() (the method that facilitates the foreach statement) is the way forward. This is very much like Ruby's Enumeration mixin (http://ruby-lang.org/)
 I assume
 they are just as powerful or more powerful than C++, but...
Yes, but in different ways. We are all just learning about the ramifications of this.
May 01 2004