www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 'delete' keyword

reply %u <wfunction hotmail.com> writes:
Hi,

I just found out that the 'delete' keyword is intended to be deprecated, and I
wanted to share several opinions about it and make a couple of suggestions:

- Please don't remove it, at least not in D version 2. The *main* reason I've
used D is its flexibility with regard to garbage collection -- it lets the
programmer optimize his programs in ways that are not possible otherwise.

- If you remove it, you'll also be forced to remove scope(), because of the
same "dangers" -- and hence lots of optimizations when using the stack simply


management.)

- If you *MUST* remove it, do something else instead: Change it so it simply
redirects to a GC method, and have that GC method add the object to a list of
objects that should be analyzed before anything else for garbage collection
(effectively making the object become generation negative one). This will fix
safety issues (because there's no requirement for the object to be actually
freed, if there's references to it), it'll be efficient (since no collection
necessarily takes place at that moment), but it'll still give the programmer
control over object lifetimes, and prevent issues like midlife crisis. (I'll
still cry over the fact that the old 'delete' will be gone, but less than if
this feature wasn't present.) :)

- An alternative solution to removing 'delete' (which I would highly advocate)
is for it to still delete the object, but call a logging function (which can
be activated at run time) to write down which exact chunks of memory were
collected. That way, if an access violation later happens, the programmer can
simply look at the address and notice that it was previously allocated by
objects X, Y, and Z, and then he can look for where the problems were. I'd
personally say that this is probably better than any other solution, because
(a) the programmer can activate or deactivate the logging at will, and (b)
it'll facilitate debugging but still make D be the powerful language it is.

Again, PLEASE continue supporting the keyword, even if it means the program
has to be given a big red "COMPUTER HAZARD" stamp or something... :) otherwise
D will just no longer be the powerful language it is.

(I'm curious to see what people think of the debugging feature? Opinions are
very welcome!)


And thank you for making D the great language it is! :)
Jan 04 2011
next sibling parent %u <wfunction hotmail.com> writes:
Sorry for the second email, but another idea I forgot to mention is this:

Instead of logging (or even with logging!), allow a debug feature where the
'delete' keyword would walk all of the memory and check for references to the
object before actually deleting it, and if there's a problem, just have it do an
assert(0). This will make debugging a breeze, and it would pretty much clear up
any problems with safety and all.

Does that sound like a good (and reasonably simple) option?

Thank you!
Jan 04 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Here comes the sh*tstorm..

(we had this topic already)
Jan 04 2011
parent reply %u <wfunction hotmail.com> writes:
Oops, very sorry about that... in that case, please do feel free to completely
ignore those!! I won't feel bad! :)
Jan 04 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/5/11, %u <wfunction hotmail.com> wrote:
 Oops, very sorry about that... in that case, please do feel free to
 completely
 ignore those!! I won't feel bad! :)
No, I'm just saying you should take a look at previous thread because they might already answer some of your questions. Feel free to ask more questions/propose new ideas though!
Jan 04 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
s/singular/plural

On 1/5/11, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 1/5/11, %u <wfunction hotmail.com> wrote:
 Oops, very sorry about that... in that case, please do feel free to
 completely
 ignore those!! I won't feel bad! :)
No, I'm just saying you should take a look at previous thread because they might already answer some of your questions. Feel free to ask more questions/propose new ideas though!
Jan 04 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, January 04, 2011 18:31:25 %u wrote:
 Hi,
 
 I just found out that the 'delete' keyword is intended to be deprecated,
 and I wanted to share several opinions about it and make a couple of
 suggestions:
 
 - Please don't remove it, at least not in D version 2. The *main* reason
 I've used D is its flexibility with regard to garbage collection -- it
 lets the programmer optimize his programs in ways that are not possible
 otherwise.
 
 - If you remove it, you'll also be forced to remove scope(), because of the
 same "dangers" -- and hence lots of optimizations when using the stack


 flexibility in memory management.)
 
 - If you *MUST* remove it, do something else instead: Change it so it
 simply redirects to a GC method, and have that GC method add the object to
 a list of objects that should be analyzed before anything else for garbage
 collection (effectively making the object become generation negative one).
 This will fix safety issues (because there's no requirement for the object
 to be actually freed, if there's references to it), it'll be efficient
 (since no collection necessarily takes place at that moment), but it'll
 still give the programmer control over object lifetimes, and prevent
 issues like midlife crisis. (I'll still cry over the fact that the old
 'delete' will be gone, but less than if this feature wasn't present.) :)
 
 - An alternative solution to removing 'delete' (which I would highly
 advocate) is for it to still delete the object, but call a logging
 function (which can be activated at run time) to write down which exact
 chunks of memory were collected. That way, if an access violation later
 happens, the programmer can simply look at the address and notice that it
 was previously allocated by objects X, Y, and Z, and then he can look for
 where the problems were. I'd personally say that this is probably better
 than any other solution, because (a) the programmer can activate or
 deactivate the logging at will, and (b) it'll facilitate debugging but
 still make D be the powerful language it is.
 
 Again, PLEASE continue supporting the keyword, even if it means the program
 has to be given a big red "COMPUTER HAZARD" stamp or something... :)
 otherwise D will just no longer be the powerful language it is.
 
 (I'm curious to see what people think of the debugging feature? Opinions
 are very welcome!)
 
 
 And thank you for making D the great language it is! :)
This has been discussed at length before. Andrei is against delete, and actually deleting stuff on the GC heap can cause problems. I believe that there is a gc_malloc() and gc_free() that will allow you to do that if you really want to. I believe that there are other functions for disabling the garbage collector and telling it to collect garbage if you want to do that. However, I'm not all that well-versed in what functions exist to manipulate the GC. Really, the idea is that normally, you'd just use the GC and not worry about it unless profiling shows that you have an issue somewhere, and then you tweak that one spot. clear() is intended to be used when you want to call the destructor on an object on the heap so that it can clean up its resources which aren't memory resources. The object is then supposed to have its vtable nulled-out so that you get a segfault if your code tries to use that object, but I'm not sure that it's currently implemented to do that yet (it at least used to put the object in the state that its in just prior to a constructor being called on it). Because it is unsafe, scope is going away as a modifier on a local variable (though scope statements are remaining and scope on function parameters is staying - though I don't recall what that really does, since it's not the same as marking a local variable with scope). However, I believe that there is a scoped template which has been added to std.typecons to take its place. So, if you _really_ want to use it, it's there. If you're doing that a lot though, you might want to rethink things so that you're using structs instead of classes. Using structs and templates goes a long way without needing classes and the polymorphism that they have, so a lot of D programs don't need the heap all that much. Use classes only if you actually need them. I'm sure that someone else will chime in with better info, but delete is definitely going away. It's been argued before, and I really don't think that the folks who want delete to stay are going to convince Andrei. - Jonathan M Davis
Jan 04 2011
next sibling parent %u <wfunction hotmail.com> writes:
Oh haha all right, thank you both for the great info! I'll definitely re-read
the
previous threads; sorry to post on a duplicate topic. :)
Jan 04 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 However, I believe that there is a 
 scoped template which has been added to std.typecons to take its place.
Currently the "replacements" for scope e typedef are worse than what they replace: http://d.puremagic.com/issues/show_bug.cgi?id=5115 They are "better" because they are library-based, so there's hope to see them improve. But D may need other general features to replace the specialized features used by scope and typedef. Bye, bearophile
Jan 05 2011
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
%u Wrote:

 Hi,
 
 I just found out that the 'delete' keyword is intended to be deprecated, and I
 wanted to share several opinions about it and make a couple of suggestions:
Hey, I'm the one how started the other thread you saw. It was definitely not about whether delete should exist or not. I updated my answer on SO such that it is clearer how delete was replaced, though it still isn't something you should concern your self with most of the time. "You don't. Delete is not to be used with D version 2 and intended to be removed from the language. What the hold up is, I am not sure. Instead you use a function, clear(object), which calls the destructor where you can free resources that are not GC memory. The distructor will be caused again during GC collection of the objects own memory. This is explained in "The D Programming Language". "The idea is to reclaim resources earlier than what the GC would provide and prevents memory corruption from dangling pointers. To be less safe the core.memory module provides GC.free(object) which can be used to free the memory, after calling clear(object). "As I'm not a C++ programmer, I don't really know the RAII pattern, but this and reference counting is the expected strategy if you wish to avoid the GC." http://stackoverflow.com/questions/4589114/when-to-delete-in-d Hope this would prevent fear of delete being removed.
Jan 05 2011