On Thu, Dec 17, 2020 at 06:10:25PM +0000, IGotD- via Digitalmars-d-learn wrote:
[...]
> b.m_buffer.length 2, b.m_buffer.capacity 31
> b.m_buffer.length 0, b.m_buffer.capacity 0
>
> capacity 0, suggests that the array has been deallocated.
Are you sure?
My understanding is that capacity is always set to 0 when you shrink an
array, in order to force reallocation when you append a new element.
The reason is this:
int[] data = [ 1, 2, 3, 4, 5 ];
int[] slice = data[0 .. 4];
writeln(slice.capacity); // 0
writeln(data.capacity); // 7 <--- N.B.
slice ~= 10;
writeln(slice); // [1, 2, 3, 4, 10]
writeln(data); // [1, 2, 3, 4, 5]
Notice that slice.capacity is 0, but data.capacity is *not* 0, even
after taking the slice. Meaning the array was *not* deallocated.
Why is slice.capacity set to 0? So that when you append 10 to it, it
does not overwrite the original array (cf. last line of code above), but
instead allocates a new array and appends to that. This is the default
behaviour because it's the least surprising -- you don't want people to
be able to modify elements of your array outside the slice you've handed
to them. If they want to append, they get a copy of the data instead.
In order to suppress this behaviour, use .assumeSafeAppend.
T
--
If you're not part of the solution, you're part of the precipitate.
