Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

Ary Borenszweig wrote:
> Andrei Alexandrescu wrote:
>> 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.
> 
> So... the library will be related somehow to the implementing compiler?

I'd believe so!

Andrei