So the delete keyword has been deprecated - so good bye manual memory management...

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?)

On Friday, 26 October 2012 at 23:03:15 UTC, Minas wrote:
> What is unsafe about it?

If you delete something but keep a reference to it, at some point down the line, the memory could be reused.

Then your old reference points to a different type of object and could treat it differently.


Just for example:

string code = something;

delete code;

// but oops code is still there and pointing at some memory...

int[] something = new int(10); // this might reuse the memory


eval(code); // now this evals a bunch of ints as if they were code which certainly isn't what you expected

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
alex@lycus.org
http://lycus.org

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.

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

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

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/hzryuifoixwwywwifwbz@forum.dlang.org

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/hzryuifoixwwywwifwbz@forum.dlang.org

If there are no lingering references, the function calling free() can safely be made @trusted.

--
  Simen

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.

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/hzryuifoixwwywwifwbz@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; }();