Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

Michel Fortin wrote:
> 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.

That is correct. The default constructor must be called for classes. For 
structs, copying .init over will do.

>> 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.

Discussion took a turn.

> 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.

I agree that some would want to manage their own allocation, and see no 
fault with a pool that exposes factory methods a la create() and 
recycle() or whatever.

The language has become larger and more powerful. Now we're in an odd 
situation: the language has become powerful enough to render obsolete 
some things that previously were in the language because they couldn't 
be expressed. Consider a factory method create(). In the olden days, 
there was no way to properly forward variadic arguments to an object's 
constructor. So repeating C++'s awful hack seemed like a reasonable 
thing to do. Now even the new keyword isn't that justified because a 
simple function could do everything new does, plus custom allocation and 
whatever if we so want.

Walter, Don and myself are looking into ways of making the language 
smaller and moving some of built-in functionality to the standard 
library. Tomasz' post on making an in-situ class instance was a 
watershed point for me. I thought about it some more and realized that 
language size and library size aren't the same thing. (I had a feeling 
before that, but no good argument.)

Language is not modular and doesn't have well-defined boundaries that 
carve subunits. Libraries do. I can always say "I will/won't use this 
module/package/library" but the language just comes at you in parallel. 
Conversely, if you see something you don't know in some code and it's in 
a library, you can always decide to look at that library's code and/or 
documentation and figure out what's what. In contrast, if I saw a 
highlighted keyword that I had no idea what it does I'd get quite worried.


Andrei