On Wednesday, 23 September 2020 at 04:15:51 UTC, mw wrote:
On Saturday, 27 October 2012 at 01:08:12 UTC, Jonathan M Davis
wrote:
Yes. But using core.memory.GC.free is unsafe for the same
reasons that delete is. It's just that it's a druntime
function instead of a part of the language, so it's less
likely for someone to free GC memory without knowing what
they're doing. It's there because there _are_ times when it
makes sense and is useful, but it's definitely not safe, so
you have to be careful and know what you're doing.
What do you mean by saying "it's definitely not safe" here?
I mean: if I'm careful and know what I'm doing, e.g. remove all
the reference to any part of the `object` before call
core.memory.GC.free(object), is there still any inherit
"unsafe" side of `free` I should be aware of?
FYI: I just described my use case here:
https://forum.dlang.org/post/hzryuifoixwwywwif...@forum.dlang.org
The logic is: @safe code isn't allowed to have access to dangling
pointers, because you're allowed to dereference pointers in @safe
code, and dereferencing a dangling pointer is undefined behavior.
Since manually freeing memory can create dangling pointers,
you're not allowed to do it in @safe code.
If you can prove with 100% certainty that you're not going to
create a dangling pointer, you can wrap the call to `free` in a
@trusted lambda:
() @trusted { free(ptr); ptr = null; }();
