On Tue, 26 Apr 2011 14:14:11 -0400, Benjamin Thaut <c...@benjamin-thaut.de> wrote:

Am 26.04.2011 19:59, schrieb Steven Schveighoffer:
On Tue, 26 Apr 2011 13:36:37 -0400, Benjamin Thaut
<c...@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.

This is no longer the case for classes. It actually runs the same function that delete runs (rt_finalize). Though, I'm not sure it's in 2.052...

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

I have not used it, but I'm under the impression from Andrei that it is to replace scope classes, so I would guess it has to work for them.

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

I think that is a good idea.

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?


disable the constructor, then use a static factory method to initialize the class with the correct heap.

If this isn't satisfactory, someone else will have to answer, I'm not really one of those who ever used custom allocators or emplace.

-Steve

Reply via email to