Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

Sean Kelly wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> dsimcha wrote:
>>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>>>> It is a bad idea because distinguishing between release of (expensive)
>>>> resources from dangerous memory recycling is the correct way to obtain
>>>> deterministic resource management within the confines of safety.
>>> This is based on two faulty assumptions:
>>>
>>> 1.  Memory is cheap.  (Not if you are working with absurd amounts of data).
>>> 2.  Garbage collection is never a major bottleneck.  (Sometimes it's a worthwhile
>>> tradeoff to add a few manual delete statements to code and sacrifice some safety
>>> for making the GC run less often.)
>> malloc.
> 
> So for placement construction of a class, I guess it would look something like:
> 
> auto x = cast(MyClass) malloc(MyClass.classinfo.init.length);
> x.__ctor( a, b, c ); // construct
> ...
> x.__dtor();
> free( cast(void*) x );
> 
> Is that right?

Yes, I think so, but I haven't checked all the details. For example I'm 
not sure whether __ctor copies .init over the memory before running the 
user-defined constructor, or expects that to have been done already.

My understanding from Walter is that __ctor(x, y, z) are simply the 
functions this(x, y, z) as written by the user, so you'd need to memcpy 
the .init by hand before calling __ctor.

Aw hell I got curious so let me check.

class MyClass {
     int x = 42;
     this() {}
}

void main() {
     auto x = cast(MyClass) malloc(MyClass.classinfo.init.length);
     x.__ctor();
     writeln(x.x);
     writeln(x.toString);
}

That prints 0 and then crashes on my machine. Looks like you need to 
memcpy the .init before calling __ctor.

I'm very glad we're starting to look into this. There are very nice 
opportunities for adding custom allocation support in the stdlib.


Andrei