Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

grauzone wrote:
> Andrei Alexandrescu wrote:
>> 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.
> 
> Apparently it doesn't: 
> http://www.digitalmars.com/techtips/class_objects.html
> 
> See, it's even documented.
> 
> Anyway, does your statement mean that _ctor is officially supported (by 
> all conform D compilers)?
> 
> Because, quoting from the page above:
> "This technique goes "under the hood" of how D works, and as such it is 
> not guaranteed to work with every D compiler. In particular, how the 
> constructors and destructors are called is not necessarilly portable."

That technique will be used by a library function.

Andrei