3 ms·
Novice question about D: From my brief reading, it looks like appending to a slice in D avoids the "invalidate all references into the old allocation" problem i
by oconnor663 4y ago
Novice question about D: From my brief reading, it looks like appending to a slice in D avoids the "invalidate all references into the old allocation" problem in a similar way to how Go does it, by having the GC keep the old allocations alive as long as there are references into them. Is that right? How does that interact with optional garbage collection? Is there anything like C++'s std::vector or Rust's Vec that D programmers reach for when the GC is off?
- mhh__ 4y agoNot really. It's basically the holy grail for any future lifetime proposals for D. The GCC static analyzer is actually clever enough to spot these types of bugs (memory ones anyway, not database handles) but this doesn't scale.
- dukc 4y agoYes, that is correct. There are all kinds of gc-less containers implemented for D, including the standard library std.container.array that is much like C++ std::vector. The downside of those is that they are not entirely memory safe. EDIT: Even slices do not mandate using the GC. The GC will only collect arrays registered to it in the first place. If the slice was malloced, it is not registered and thus won't be collected. The built-in ~ operator allocates the new array with the GC though, so you have do something custom to concatenate slices in GC-free code.