Eliminate class allocators and deallocators?

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2009-10-06 20:26:48 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> 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's a safety hack, not a performance hack.
> 
> In my opinion, it's mostly an illusion of safety. If you call the 
> destructor on an object, the object state after the call doesn't 
> necessarily respects the object invariants and doing anything with it 
> could result in, well, anything, from returning wrong results to falling 
> into an infinite loop (basically undefined behaviour). What you gain is 
> that no object will be allocated on top of the old one, and thus new 
> objects can't get corrupted. But it's still undefined behaviour, only 
> with less side effects and more memory consumption.
> 
> I don't think it's a so bad idea on the whole, but it'd be more valuable 
> if accessing an invalidated object could be made an error instead of 
> undefined behaviour. If this can't be done, then we should encourage 
> "destructors" to put the object in a clean state and not leave any dirt 
> behind. But should that still be called a "destructor"?
> 
> Perhaps we could change the paradigm a little and replace "deletion" 
> with "recycling". Recycling an object would call the destructor and 
> immeditately call the default constructor, so the object is never left 
> in an invalid state. Objects with no default constructor cannot be 
> recycled. This way you know memory is always left in a clean state, and 
> you encourage programmers to safely reuse the memory blocks from objects 
> they have already allocated when possible.

Yes, recycling is best and I'm considering it. I'm only worried about 
the extra cost.

Andrei