www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why is "delete" unsafe?

reply "Minas" <minas_mina1990 hotmail.co.uk> writes:
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?)
Oct 26 2012
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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
Oct 26 2012
prev sibling next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
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
Oct 26 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Oct 26 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Oct 26 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Oct 26 2012