www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - vestigial delete in language spec

reply "Dan" <dbdavidson yahoo.com> writes:
TDPL states
------
However, unlike in C++, clear does not dispose of the object’s
own memory and there is no delete operator. (D used to have a
delete operator, but it was deprecated.) You still can free
memory manually if you really, really know what you’re doing by
calling the function GC.free() found in the module core.memory.
------
The language spec has this example from the section on Struct
Postblits:
------
struct S {
    int[] a;    // array is privately owned by this instance
    this(this) {
      a = a.dup;
    }
    ~this() {
      delete a;
    }
}
------

Is the delete call, then per TDPL not necessary? Is it harmful or
harmless?

Also, are there any guidelines for using and interpreting the 
output of
valgrind on a D executable?

Thanks
Dan
Nov 01 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 01-11-2012 22:21, Dan wrote:

 TDPL states
 ------
 However, unlike in C++, clear does not dispose of the object’s
 own memory and there is no delete operator. (D used to have a
 delete operator, but it was deprecated.) You still can free
 memory manually if you really, really know what you’re doing by
 calling the function GC.free() found in the module core.memory.
 ------
 The language spec has this example from the section on Struct
 Postblits:
 ------
 struct S {
     int[] a;    // array is privately owned by this instance
     this(this) {
       a = a.dup;
     }
     ~this() {
       delete a;
     }
 }
 ------

 Is the delete call, then per TDPL not necessary? Is it harmful or
 harmless?

 Also, are there any guidelines for using and interpreting the output of
 valgrind on a D executable?

 Thanks
 Dan


The docs are supposed to not use delete. In this particular case, you'd 
use core.memory.GC.free(a.ptr); instead.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Nov 01 2012
prev sibling next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/01/2012 02:21 PM, Dan wrote:


 TDPL states
 ------
 However, unlike in C++, clear does not dispose of the object’s
 own memory and there is no delete operator.


Additionally, TDPL predates 'clear's deprecation in December 2012. It is 
called 'destroy' now.

Ali
Nov 01 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 01, 2012 22:21:11 Dan wrote:

 struct S {
 int[] a; // array is privately owned by this instance
 this(this) {
 a = a.dup;
 }
 ~this() {
 delete a;
 }
 }

 Is the delete call, then per TDPL not necessary? Is it harmful or
 harmless?


It's not necessary at all. delete is _never_ necessary, and it's not safe. 
delete frees GC-allocated memory. If you just leave it alone, and there are 
really no other references to it, then the GC will eventually free it if it 
needs more memory. Deleting it makes it so that it's freed now rather than 
freed who-knows-when later, but if any other references to that data still 
exist when it's deleted, then they'll end up pointing to garbage behavior, 
giving you nasty bugs.

Because of all of this, delete is going to be deprecated if it hasn't been 
already. core.memory will still provide functions for freeing GC memory if you 
really want to and are willing to go the extra mile to make sure that your 
code is safe, but there will no longer be a language primitive for doing so.

clear (which was recently renamed to destroy) specifically destroys an object 
but does _not_ free its memory. So, you won't end up with bugs due to other 
references to that data operating on garbage. In the case of classes, because 
destroy zeroes out the vtbl, calling virtual functions on the destroyed object 
will cause a segfault. In the case of primitives such as int, I believe that 
they're set to their init property. And in the case of arrays, I believe that 
it's no different from setting them to null, so nothing else is actually 
affected by calling destroy on them. Regardless, with destroy, you're not going 
to run into nasty memory issues due to memory being freed when other 
references to it still existed, because it doesn't actually free any memory. 
It just destroys what's there so that fewer references to it exist and so that 
any non-GC-allocated resources which the destroyed object had get released.

- Jonathan M Davis
Nov 01 2012
prev sibling parent Don Clugston <dac nospam.com> writes:
On 01/11/12 22:21, Dan wrote:

 TDPL states
 ------
 However, unlike in C++, clear does not dispose of the object’s
 own memory and there is no delete operator. (D used to have a
 delete operator, but it was deprecated.) You still can free
 memory manually if you really, really know what you’re doing by
 calling the function GC.free() found in the module core.memory.
 ------
 The language spec has this example from the section on Struct
 Postblits:
 ------
 struct S {
     int[] a;    // array is privately owned by this instance
     this(this) {
       a = a.dup;
     }
     ~this() {
       delete a;
     }
 }
 ------

 Is the delete call, then per TDPL not necessary? Is it harmful or
 harmless?

 Also, are there any guidelines for using and interpreting the output of
 valgrind on a D executable?

 Thanks
 Dan


You'll probably have trouble getting much out of valgrind, because it 
doesn't support 80-bit floating instructions, unfortunately.
Nov 02 2012