Eliminate class allocators and deallocators?

[Michel Fortin]

On 2009-10-07 08:46:06 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> 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
michel.fortin at michelf.com
http://michelf.com/