Eliminate class allocators and deallocators?

[Jeremie Pelletier]

Leandro Lucarella wrote:
> Andrei Alexandrescu, el  7 de octubre a las 15:23 me escribiste:
>> Leandro Lucarella wrote:
>>> Andrei Alexandrescu, el  7 de octubre a las 14:16 me escribiste:
>>>> 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.
>>> What I don't understand is why you're willing to make that hard to do
>>> manual memory management in D. Do you see that you're making the
>>> programmer's job deliberately for no reason? D needs conservative GC,
>>> which means slow GC; by definition. D is a system programming language, so
>>> it's expected to be fast, but because of the GC there will be often
>>> situations where you have to do manual MM. Why are you making that much
>>> harder?
>>>
>>> You know that in the search for safety you'll be making much more unsafe
>>> (or bug-prone) to do manual MM?
>> You seem to be asserting that without additional built-in language
>> support, manual memory management is unduly difficult. Why so?
> 
> Because of this:
> 
>>>>> auto x = cast(MyClass) malloc(MyClass.classinfo.init.length);
>>>>> x.__ctor( a, b, c ); // construct
>>>>> ...
>>>>> x.__dtor();
>>>>> free( cast(void*) x );
> 
> :)
> 
> You even forgot to register your object as a root in the GC, so if your
> MyClass has any pointers to the GC your program will blow in your face.
> 
> If you plan to library support to ease this and avoid repetitive and
> bug-prone work, you can ignore my complains...
> 

I agree, that manual allocation code looks plain ugly. Why should we 
remove delete from the language anyways? If its unsafe then don't use it 
and your memory will get collected someday. If you need to reclaim 
memory right away, or you're doing manual memory management then its 
there, just like the original spec said.

We can't always just let the GC collect everything, its most useful for 
memory that travels around a lot like strings and whatnot, but it's 
definitely too slow and too memory hungry for performance code.

 From the testing I did the D garbage collector is very fast to allocate 
memory, but *very* slow to reclaim it by mark&sweep, yet reclaim by 
delete is as fast as allocating it.

The argument that it may be safer doesn't count, cause you can just not 
call delete and have safe code.

I vote to keep delete in D.