Eliminate class allocators and deallocators?

[Christopher Wright]

Andrei Alexandrescu wrote:
> 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.

Memory safety, sure, but you're deleting the object. It is no longer 
valid. You need to add a flag to the object indicating it's invalid, and 
everything that uses it needs to check that flag. Instead of a probable 
segfault in the current system, you'll get strange errors.

It sounds like a complicated way of supporting a rare use case. Why not 
use a library solution? Make an IDisposable interface with methods "void 
dispose()" and "bool disposed()"?

If you don't have enough time to explain the reasoning, could you post a 
link to a more detailed explanation?