DIP 1025--Dynamic Arrays Only Shrink, Never Grow--Community Review Round 1

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Nov 11 12:27:11 UTC 2019

On Monday, November 11, 2019 5:15:23 AM MST Dukc via Digitalmars-d wrote:
> On Monday, 11 November 2019 at 11:51:09 UTC, Jonathan M Davis
> wrote:
> > IMHO, the ability to append to a dynamic array without caring
> > whether it's backed by GC-allocated memory, malloc-ed memory,
> > stack allocated memory, or whatever is a huge benefit.
> Yeah... And I definitely think all of these should continue to
> exist with the possible exception of malloced memory.
> > Right now, you can pass a dynamic array that isn't backed by
> > the GC to a function, and it all just works even if the
> > function needs to do a reallocation to make the array large
> > enough. Doing so is not necessarily a bug and allows you to use
> > non-GC allocated memory where appropriate while still being
> > able to grow the array, and it does so without the code having
> > to care about what kind of memory is currently backing the
> > dynamic array.
> But chances are that if you grow a malloced slice bu GC, you
> cause a memory leak, and that's what Walter is trying to solve.
> On the other hand, there should be a way for the caller to
> explicitly allow a function to grow a GC-allocated slice, without
> touching the function, and my idea does not solve that. I dunno...

Whether you risk causing a memory leak or not doesn't really have anything
to do with whether reallocations can occur. The code needs to be aware of
when the malloc-ed memory is definitely no longer used and then manually
free it. It's certainly true that the lack of reference counting makes it
harder to write code that uses slices of malloc-ed memory, but having slices
of malloc-ed memory poses exactly the same risks of keeping those slices
around too long whether ~= works on them or not. You either write the code
in a way that you know when the slices are no longer used so that you know
when you can free the memory, or you don't slice non-GC-allocated memory.

- Jonathan M Davis

More information about the Digitalmars-d mailing list