On 2009-10-07 08:46:06 -0400, Andrei Alexandrescu
<[email protected]> said:
You're right. It would be great to dispose of the delete keyword and
define a member function and/or a free function that invokes the
destructor and obliterates the object with its .init bits.
I guess I should have read this before posting mine. :-)
You're suggesting obiterating with the .init bits, but I believe this
is insufficient: you need to call a constructor if you want to be sure
object invariants holds. If you can't make the invariants hold, you're
in undefined behaviour territory.
At any rate: deletion + memory reclamation must go. If you want to do
manual memory management, malloc/free are yours. D's native GC heap is
not the right place.
Well, yes you're entirely right saying that. But I fail to see how this
is linked to class allocators and deallocators. Class allocators and
deallocators are just a way to tell the runtime (including the GC) how
to allocate and deallocate a specific class of objects. There is no
need to manually call delete for the allocator and deallocator to be
useful.
The way it is currently, if you want objects of a certain class to be
allocated in one big object pool, you can encapsulate that detail in
the class so clients don't have to bother about it. I've done that in
C++ to speed up things without having to touch the rest of the code
base and it's quite handy.
At other times the client of the class that wants to manage memory, and
that should be allowed too, bypassing the class's allocator and
deallocator and calling directly the constructor and destructor.
--
Michel Fortin
[email protected]
http://michelf.com/
