auto classes and finalizers

[Regan Heath]

On Sun, 09 Apr 2006 22:21:39 -0700, kris <foo at bar.com> wrote:
> Regan Heath wrote:
>
>> I have. Here is what you say WRT leaks:
>>
>>> What about implicit cleanup? In this scenario, it doesn't happen. If  
>>> you  don't explicitly (via delete or via raii) delete an >object, the  
>>> dtor is  not invoked. This applies the notion that it's better to have  
>>> a leak  than a dead program. The leak is a bug >to be resolved.
>>   Whereas using my suggestion we get implicit cleanup. Auto propagates  
>> as  required, dtors are added and delete is called automatically where   
>> required resulting in no leaks. The best part is that the compiler   
>> enforces that by default and you have to opt-out with 'shared' to   
>> introduce a leak.
>>  So, assuming it's workable (Walters call) and it's not too inflexible  
>> I  think it's a better solution. In short, I would rather not have to   
>> explicitly manage the resources if at all possible (and I still hope  
>> it  might be).
>
> I thought the idea was that classes with dtors are /intended/ to be  
> explicitly cleaned up?

Not my idea ;) I think any given resource has a correct time/place for  
cleanup, we just need a way to specify that, ideally one that can do so  
and avoid as much human error as possible (AKA resource leaks).

> That, implicit cleanup of resources (manana, some time) was actually a  
> negative aspect? At least, that's what Mike was suggesting, and it  
> seemed like a really good idea.

It's certainly a simple solution to the problem, it may be that it's also  
the best, more use-cases will convince me (at least) one way of the other.

> Along those lines, what I was suggesting is to enable dtors for explicit  
> cleanup only. Plus an optional runtime leak detector. I guess I like the  
> simplicity of that. What you suggest seems workable too, but perhaps a  
> little more involved?

It's certainly more involved. It can't be done without changes to the  
compiler, but, once those are in place it can guarantee resources are  
cleaned up and it can guarantee no leaks occur. (assuming I'm not missing  
something obvious). The price paid for that is some flexibility (perhaps,  
perhaps not - I want more use-cases to try it with), I reckon the price is  
worth the benefit.

Regan