On Wednesday, 4 May 2022 at 08:23:33 UTC, Mike Parker wrote:
On Wednesday, 4 May 2022 at 05:37:49 UTC, forkit wrote:
That's not at all what I said. You don't have to care about
*when* memory is deallocated, meaning you don't have to
manage it yourself.
In any case, I disagree that caring about when memory gets
deallocted means you shouldn't be using GC. (or did I get that
one wrong too??)
You can have the best of both worlds, surely (and easily).
This (example from first post):
void main(){
int[] i = new int[10000];
import object: destroy;
destroy(i);
import core.memory: GC;
GC.free(GC.addrOf(cast(void *)(i.ptr)));
}
All you're doing here is putting unnecessary pressure on the
GC. Just use `malloc` and then `free` on `scope(exit)`. Or if
you want to append to the array without managing the memory
yourself, then use `std.container.array` instead. That's made
for deterministic memory management with no GC involvement.
Reverting to C style 'malloc and free' is not the solution here,
since the intent is not to revert to manually managing
dynamically allocated memory.
Rather, the intent was to just have 'a simple form of control'
over the lifetime of the dynamically allocated memory - the
object being pointed to in GC memory pool.
I understand that my idea may put uncessary pressure on the
existing GC, but a GC (in theory) could surely handle this
scenario..
If D had such a feature, I'd already be using it.
