Andrei Alexandrescu wrote:
Hello,
D currently allows defining class allocators and deallocators. They have
a number of problems that make them unsuitable for D 2.0. The most
obvious issue is that D 2.0 will _not_ conflate destruction with
deallocation anymore: invoking delete against an object will call
~this() against it but will not recycle its memory. In contrast, class
deallocators are designed around the idea that invoking delete calls the
destructor and also deallocates memory.
So I'm thinking of removing at least class deallocators from the
language. Class allocators may be marginally and occasionally useful if
the user takes the matter of deallocation in her own hands.
A much better way to handle custom allocation of classes would be in the
standard library.
What do you think?
Andrei
I wouldn't like delete to go away at all, I use it for all my non-gc
objects like this watered down example:
class ManualObject : Object {
new(size_t size) { return malloc(size); }
delete(void* mem) { free(mem); }
}
And then I can easily subclass it for any objects that doesn't need the
GC. I've got similar constructs for arrays and structs.
malloc/free are nice, but they don't allow for elegant abstractions like
new/delete does (for example if you want to use a specialized non-gc
allocator you can just replace a few calls instead of every allocation).
I also use delete when I no longer need large blocks of memory, I don't
want them to just become uninitialized and sitting on the GC. When I
want to do that I just nullify my references.
If you're afraid of deleting an object that may still have valid
references, use smart pointers, or don't delete it at all if it sits on
the gc and just call a .destroy() method.
Also in my runtime the delete implementations do free the memory, they
don't just call the finalizer.
In any ways, just don't remove new/delete overrides from the language
please, just call it a low-level technique or something to scare the
beginners away and let people who want it have it :)
Jeremie
