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