digitalmars.D - 'delete' keyword
- %u (36/36) Jan 04 2011 Hi,
- %u (8/8) Jan 04 2011 Sorry for the second email, but another idea I forgot to mention is this...
- Andrej Mitrovic (2/2) Jan 04 2011 Here comes the sh*tstorm..
- %u (2/2) Jan 04 2011 Oops, very sorry about that... in that case, please do feel free to comp...
- Andrej Mitrovic (4/7) Jan 04 2011 No, I'm just saying you should take a look at previous thread because
- Andrej Mitrovic (2/10) Jan 04 2011
- Jonathan M Davis (29/77) Jan 04 2011 This has been discussed at length before. Andrei is against delete, and ...
- %u (2/2) Jan 04 2011 Oh haha all right, thank you both for the great info! I'll definitely re...
- bearophile (6/8) Jan 05 2011 Currently the "replacements" for scope e typedef are worse than what the...
- Jesse Phillips (7/11) Jan 05 2011 Hey, I'm the one how started the other thread you saw. It was definitely...
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
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
Here comes the sh*tstorm.. (we had this topic already)
Jan 04 2011
Oops, very sorry about that... in that case, please do feel free to completely ignore those!! I won't feel bad! :)
Jan 04 2011
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
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
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
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
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
%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