Re:Memory Safety in a Modern System Programming Language Pt. 1
by oconnor663 on Wednesday June 22, 2022 @03:25PM
(#31840671)
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?
[ Parent
| on HN ]
Re:Memory Safety in a Modern System Programming Language Pt. 1
by dukc on Wednesday June 22, 2022 @05:36PM
(#31842168)
Yes, 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.
Re:Memory Safety in a Modern System Programming Language Pt. 1
by mhh__ on Wednesday June 22, 2022 @04:30PM
(#31841491)
Not 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.