deprecated delete and manual memory management

[Benjamin Thaut]

Am 26.04.2011 19:59, schrieb Steven Schveighoffer:
> On Tue, 26 Apr 2011 13:36:37 -0400, Benjamin Thaut
> <code at benjamin-thaut.de> wrote:
>
>> I've been reading through various delete topics in the past hour, but
>> couldn't find any statement on how manual memory management would
>> look, if the delete operator is deprecated. Something like the
>> following seems really odd:
>>
>> class foo {
>> public new(size_t sz){ //language support
>> return malloc(sz);
>> }
>>
>> public void Delete(){ // no language support ??
>> this.__dtor();
>> free(this);
>> }
>> }
>>
>> auto fooInst = new foo(); //language support
>> fooInst.Delete(); //no language support ??
>
> IIUC, the custom allocator will be deprecated as well.
>
> What I think you need to use instead is emplace (a phobos function, not
> sure where it is), clear, and GC.free.
>
> Andrei hinted at a not-yet-written drop-in replacement for delete, but
> I'm not sure how that looks.
>
> -Steve

I don't want to use the GC at all, and clear() seems inefficent, since 
it reaintializes the object. This is unneccsary since I just want to 
throw it away anyway.

emplace only works for structs, it does not work for classes.

Could someone please write a small example how manual memory management 
would look without new / delete?

When the new operator can not be overloaded anymore, what happens when I 
dedicde to manualy manage the memory for a certain class? I then would 
have to search and replace every single new statement for that class. 
What happens when I forgett one? Some of my instances will then be on 
the GC heap and some on the self managed heap?

-- 
Kind Regards
Benjamin Thaut