Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

Christopher Wright wrote:
> What exactly is your suggestion?
> 
> It seems that you mean that:
> delete obj;
> 
> should call a destructor but not call delete() or notify the GC that the 
> memory is free.

That is correct. In particular, an object remains usable after delete.

> You're saying that there is a problem, but you're not telling us what's 
> wrong. Why the hell do you want to destroy an object without recycling 
> its memory? Why does the inability to do so cause a problem?

The matter has been discussed quite a bit around here and in other 
places. I'm not having as much time as I'd want to explain things. In 
short, destroying without freeing memory avoids dangling references and 
preserves memory safety without impacting on other resources.

> It seems like a performance hack to me -- you've got an object that 
> isn't valid anymore, but you want to hang on to the memory for some 
> other purpose. And you could override new() and delete(), but you don't 
> want to incur the performance penalty of calling the runtime to fetch 
> the deallocator.

It's a safety hack, not a performance hack.

> The only remaining use that I see is a way to reset a shared object 
> without explicitly passing around a reference to the new version of the 
> object. This seems potentially dangerous, and nothing I want for default 
> behavior.

Well incidentally at least as of now "delete obj" puts null in obj...


Andrei