Re: Why is "delete" unsafe?
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; }();
Re: Why is "delete" unsafe?
On Wednesday, 23 September 2020 at 04:15:51 UTC, mw wrote:
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?
'"delete" is unsafe' doesn't mean 'any program which uses
"delete" is unsafe'. What it means is, in a language that has
'delete', /some/ programs will be unsafe. If your language has
delete, you cannot guarantee that programs will be safe.
Now, D is not safe by default ('delete' would definitely be
disallowed in @safe code), but it still wants to have features
that /encourage/ safety (fat pointers are a great example of
this).
'delete' and 'free' are both equally unsafe; however, if you have
verified that your usage of them is safe, it is fine to use them.
Re: Why is "delete" unsafe?
On Wednesday, 23 September 2020 at 04:15:51 UTC, mw wrote: 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 If there are no lingering references, the function calling free() can safely be made @trusted. -- Simen
Re: Why is "delete" unsafe?
On Saturday, 27 October 2012 at 01:08:12 UTC, Jonathan M Davis wrote: On Saturday, October 27, 2012 01:09:39 Alex Rønne Petersen wrote: On 27-10-2012 01:03, Minas wrote: > So the delete keyword has been deprecated - so good bye > manual memory management... Um, no. Use destroy() from the object module instead. Definitely, though it's important to note that what it's doing is inherently different. It destroys what you pass to it but does _not_ free the memory, which is why it's safer. To free memory from the GC, use core.memory.GC.free(). 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
Re: Why is delete unsafe?
On 27-10-2012 01:03, Minas wrote: So the delete keyword has been deprecated - so good bye manual memory management... Um, no. Use destroy() from the object module instead. To free memory from the GC, use core.memory.GC.free(). I have read in some threads that delete is an unsafe operation. What does this exactly mean? What is unsafe about it? What does it have to do with the GC? (if there was no garbage collection, would it be unsafe?) void* p = malloc(__traits(classInstanceSize, Object)); p[0 .. __traits(classInstanceSize, Object)] = typeid(Object).init[]; Object o = cast(Object)p; delete o; // Spot the bug. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Why is delete unsafe?
On Sat, Oct 27, 2012 at 01:03:14AM +0200, Minas wrote: So the delete keyword has been deprecated - so good bye manual memory management... Um, that's a misconception. If you want manual memory management, use malloc(), free(), and emplace. I have read in some threads that delete is an unsafe operation. What does this exactly mean? What is unsafe about it? What does it have to do with the GC? (if there was no garbage collection, would it be unsafe?) The problem is that you can call delete on GC'd objects, which in some cases causes bad interaction with the GC. That's why it has been deprecated. The intention was never to get rid of manual memory management. It was to prevent unsafe interactions with the GC. If you don't want to use the GC, use malloc(), free(), and emplace. (In fact, this way you can have *both* GC and manual memory management. The emplace()'d objects will be manually managed, and the others will be collected by the GC.) T -- All men are mortal. Socrates is mortal. Therefore all men are Socrates.
Re: Why is delete unsafe?
On Friday, October 26, 2012 16:12:15 H. S. Teoh wrote: The problem is that you can call delete on GC'd objects, which in some cases causes bad interaction with the GC. That's why it has been deprecated. The intention was never to get rid of manual memory management. It was to prevent unsafe interactions with the GC. If you don't want to use the GC, use malloc(), free(), and emplace. (In fact, this way you can have *both* GC and manual memory management. The emplace()'d objects will be manually managed, and the others will be collected by the GC.) Exactly. In general, you should do manual memory management with memory that is manually allocated and _not_ with memory which is GC-allocated (which is where delete goes wrong). - Jonathan M Davis
Re: Why is delete unsafe?
On Saturday, October 27, 2012 01:09:39 Alex Rønne Petersen wrote: On 27-10-2012 01:03, Minas wrote: So the delete keyword has been deprecated - so good bye manual memory management... Um, no. Use destroy() from the object module instead. Definitely, though it's important to note that what it's doing is inherently different. It destroys what you pass to it but does _not_ free the memory, which is why it's safer. To free memory from the GC, use core.memory.GC.free(). 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. - Jonathan M Davis
