|
Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
|
D - D arrays
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → 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.
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/
↑ ↓ ← → "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/
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → "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
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
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
it's possible to get about 98% of the way to a natural integration with
language, but that 2% is not possible and pretty tricksy<shameless plug>
Matthew
↑ ↓ ← → 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]
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> 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]
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/
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → "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
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
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. ;)
↑ ↓ ← → "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
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
certainly be adequate support in terms of operator overloading such
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
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
Not what I'm suggesting. I am suggesting that there would be classes that
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 :)
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → "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
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
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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
|
|