www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - array slicing policy

reply HOSOKAWA Kenchi <hskwk inter7.jp> writes:
Hello,


D's array slicing is basically "an array means to specify a subarray of it. An
array slice does not copy the data, it is only another reference to it."
This definition, however, is easily violated by instance reallocation such as
changing its length:

int[] a = [0, 1, 2];
int[] b = a[0..2];
writeln(a.ptr, " ", b.ptr);
assert(a[0]==b[0]);

a.length = 2;
b[0] = -5;
writeln(a.ptr, " ", b.ptr);
assert(a[0]==b[0]);

a.length = 1000;
b[0] = int.min;
writeln(a.ptr, " ", b.ptr);
assert(a[0]==b[0]); // might fail


I won't be annoyed by this violation (with coding carefully) but it is only my
own impression.
How would you think of D's array slicing policy?
I think that the policy may affect the design of other Range implementation
because Range in foreach might be expected to be slice-like object.
Aug 06 2009
parent reply Tim M <tim.matthews7 gmail.com> writes:
On Thu, 06 Aug 2009 04:13:07 -0400
HOSOKAWA Kenchi <hskwk inter7.jp> wrote:

 Hello,
 
 
 D's array slicing is basically "an array means to specify a subarray
 of it.

Static arrays are the same as in C but I prefer to think of dynamic arrays as a handy GC'd block of memory that comes with a free view and any additional views can be obtained at any time. This is because all views are equal including the original and there is not really any concept of 'an array as a sub of another'.
 An array slice
 does not copy the data, it is only another
 reference to it."

b = a; //sets b to reference the same data that a gets b[] = a[]; //copy a into the data block that b already points to (must match lengh) b = a.dup; //set b to reference a new copy of a (or use .idup for immutable) How would you think of D's array slicing
 policy? I think that the policy may affect the design of other Range
 implementation because Range in foreach might be expected to be
 slice-like object.

I think Andrei has mostly worked out the fundamentals of ranges and it is probably done by treating exisiting views as immutable. To conclude it works if you can guarantee that you can have all views remain valid after any changes to the data block they point too as they are not automatically updated. Also if the compiler sees an update to the length property it will insert code to re size the memory block it points too as well as update the length property. Apart from this compile time understanding of your code, dynamic arrays are interfaced with nothing but a simple struct of the length & pointer. This can be wrapped for extra security (several implementations already exist) but many like to have the maximum performance of it being lightweight.
Aug 06 2009
parent HOSOKAWA Kenchi <hskwk inter7.jp> writes:
Tim M Wrote:

 I think Andrei has mostly worked out the fundamentals of ranges and it
 is probably done by treating exisiting views as immutable.
 
 To conclude it works if you can guarantee that you can have all views
 remain valid after any changes to the data block they point too as they
 are not automatically updated.
 
 Also if the compiler sees an update to the length property it will
 insert code to re size the memory block it points too as well as update
 the length property. Apart from this compile time understanding of your
 code, dynamic arrays are interfaced with nothing but a simple struct of
 the length & pointer. This can be wrapped for extra security
 (several implementations already exist) but many like to have the
 maximum performance of it being lightweight.
 

I have once tried to implement some containers to be familiar with Range. Then I faced the view-validity problem. e.g. discontinuity in doubly-linked list. I wondered which policy is better, among three models which you pointed out: * a singleton allocator and immutable views * wrapped for extra security * leave it as unsafe but lightweight I think it is better if we can choose from these, no matter std or third party. I wish someone (or Andrei) shows us smart implementation of the Range other than array.
Aug 06 2009