The Demise of Dynamic Arrays?!
S
S at S.com
Mon Dec 14 23:25:11 PST 2009
Excuse me, because I haven't been active in the D community the last
year due to school concerns. However, I have been fiddling with the
language and on this newsgroups since 2001.
As I understand it, dynamic arrays are going away soon in D2.0 in
favor of an ArrayBuilder class.
I don't like it at all. I want to stomp my feet and throw a temper
tantrum. As far as I am concerned, T[] has always been an
array-builder. Now, I'd appreciate some considering, and that you'll
excuse my poor phrasing when it comes to terminology (I am not a
trained computer scientist).
For the last 9 years there has been problems with dynamic arrays.
Now, I intend to enumerate the problems I have encountered and propose
some solutions, but let me first describe the internals of the D Arrays
as I understand them: (To simplify)
struct Array(T) {
T* ptr;
uint length;
}
So, D basically wraps this with various syntatic sugar. Now, there
have been a variety of probelsm with using this same type for dynamic
arrays:
1) It has failed as an array builder because it does not contain the
length of the memory it references AS WELL as the actually number of
elements stored. Thus cannot do pre-allocation like vector<> in
C++STL without some GC magic. This make it slow to append.
1-Solution) So, add an additional real_length parameter to dynamic arrays.....
2) If you take a slice, it often doesn't behave as expected.
Implement a new type T[..] that are specifically slices of other
arrays. This will add another parameter that references the array
the slice came from. Thus, appending to a slice can behave as an
insertion into it's parent and other syntatic niceties.
2-Solution) I propose that this type Arr[..] would be implicitely
castable to other array types, at the expense of a dup.
3) If dynamic arrays are passed, they pass the aformentioned struct
"by-value." This however results in the ptr NOT being shared by the
function and its caller. So, if a receiving function tries to append
to them it is possible that the sender doesn't notice the array has
been moved by the memory manager.
3-Solution) So, since static arrays are now pass-by-value. Make this
true for dynamic arrays also, and provide a warning of some sort.
This would give you the expected read-only sematics of passing values
instead of the C one where [] == *. Instead the proper way to pass a
read-write dynamic array would be by reference (AKA a Handle ...
Computer Scientists solved this problem along time ago:
http://en.wikipedia.org/wiki/Handle_%28computing%29 ). Now, this
causes some overhead in terms fo double look-ups for classes which
might not need to change the pointer address -- maybe there is some way
around doing this also though?
********* Did I miss anything? Maybe my solutions are incomplete?
Please comment and revise this. I think it would be a shame to get
rid of the syntatic sugar of dynamic arrays in support of an
ArrayBuilder class/struct.
-S.
More information about the Digitalmars-d
mailing list