On Thursday, 25 February 2016 at 19:03:12 UTC, Steven
Schveighoffer wrote:
On 2/24/16 3:47 PM, Ola Fosheim Grøstad wrote:
On Wednesday, 24 February 2016 at 18:06:19 UTC, Steven
Schveighoffer wrote:
I'm quite glad D stuck with the same type for arrays and
array slices.
And how will you get around this when not having a GC?
I don't follow. D's arrays will always have a GC.
If you have a different type of array, it's a different type,
it can do whatever it wants.
Remember that a dynamic array does not necessarily refer to
GC-allocated memory. The dynamic array operations don't care
about that at all, but it does make it so that you can have a
problem figuring out when it's okay to free the memory that you
sliced them from if you start passing them around all over the
place and potentially storing them. So, in that regard, the fact
that a dynamic array doesn't really own or manage its own memory
can complicate things when the dynamic array was not allocated
via the GC (be it because it was sliced from malloced memory or
sliced from a static array or whatever).
There's also the issue that some folks disable the GC, which
doesn't prevent dynamic arrays from working aside from the few
operations that require the GC, but it does mean that you to be
that much more careful about how you use them.
Personally, I think that using malloc or a static array to back a
dynamic array works great if you're dealing with localized stuff
that you're going to pass to pure, free functions (which
therefore can't slice the dynamic array and store it elsewhere),
but once you're dealing with dynamic arrays that get passed
around and stored arbitrarily, it gets seriously iffy to slice
malloced memory or static arrays and start passing those dynamic
arrays around. It quickly becomes far more sensible to create a
container that gives you range rather than deal with dynamic
arrays.
- Jonathan M Davis
