T[new]

Brad Roberts braddr at puremagic.com
Sun Aug 9 14:05:19 PDT 2009


Walter Bright wrote:
> Brad Roberts wrote:
>> Yay.  What will happen with slices over a T[new] when the underlying
>> T[new] must
>> be moved due to resizing?  The behavior needs to be at least well
>> specified, if
>> not well defined.
> 
> Great question! It's no different from what happens with any container
> when its contents change and there are references to the old content.
> 
> What won't happen is the slice won't be pointing to unallocated memory,
> thanks to the gc. Resizing the T[new] will not cause the old contents to
> be deleted.
> 
> The slice will either point to the old content, if the resize caused a
> move, or the new content, if it was resized in place. So it will still
> be implementation-defined behavior.
> 
> But the likelihood of getting caught by such behavior is much less
> likely with T[new], as one can clearly see in the code where the
> resizeables are, rather than the current situation where any slice could
> be resized by anyone.
> 
> I think that taking a slice of a T[new], then resizing the T[new], will
> be rare (or at least should be). Normally, a T[new] will be built, and
> when it is all done, it is converted to a T[] and there is no longer any
> way to resize it.

As expected, but like I said.. this needs to be clear in the spec.  Because
something like this is just confusing (and yes, I know it's not new behavior):

    auto a = new int[10];
    a[0] = 1;
    auto s1 = a[0..1];
    a.length = <some value large enough to force a move>;
    auto s2 = a[0..1];
    s2[0] = 2;
    assert(s1[0] == s2[1]); // fail

Later,
Brad




More information about the Digitalmars-d mailing list