Array slices and copy on write

[spir]

On 04/03/2011 04:29 PM, simendsjo wrote:
> On 03.04.2011 14:55, spir wrote:
>> On 04/03/2011 02:29 PM, simendsjo wrote:
>>> D will copy the original content if a slice expands, but is the
>>> following behavior
>>> implementation specific, or part of the specification?
>>>
>>> auto a = [0,1,2];
>>> auto b = a[0..2];
>>> a.length = 2; // is a[3] already marked for collection by the gc?
>>> assert(a.ptr == b.ptr);
>>> b.length += 1; // as b cannot reuse it even though noone is using it
>>> assert(a.ptr == b.ptr); // ooops, fails.. b is reallocated
>>
>> As I understand it (there is no real spec for D), this is consistent
>> with the often commented design of D slices.
>> People often explain that slices are like views on (implicite or
>> explicit) ordinary arrays. Then, change on either is seen by both, just
>> like references --*except* when change require resizing.
>> Another point of view is that slices somewhat work like copy-on-write:
>> there is no actual copy until one variable value is changed, then only
>> copy happens --expect when change can happen on place.

I was trying to explain my views on D's slice semantics, thus showing how/why 
the above behaviour matches it.

> I know the dangers of slices and copy on write. I was thinking of a very
> specific example. I'll try to explain better.
>
> auto a = [0,1,2];
> auto b = a[0..2];
> a.length = 2;
> // a[3] should now not be referenced, but my guess is it's not collected by the gc
> assert(a.ptr == b.ptr);
> b.length += 1;
> // b could potentionally use the last part of a instead of reallocating
> // Could another implementation reuse a's old memory without reallocating?

I think this is how Go does slices (their cap(acity) extends to the end of the 
original array). For me, this would not match D's semantics, but since there is 
no spec AFAIK...

Denis
-- 
_________________
vita es estrany
spir.wikidot.com