GC and dtors ~ a different approach?

[Bruno Medeiros]

kris wrote:
> I thought it worthwhile to review the dtor behaviour and view the 
> concerns from a different direction:
> 
> dtor 'state' valid:
> - explicit invocation via delete keyword
> - explicit invocation via raii
> 
> dtor state 'unspecified':
> - implicitly called when no more references are held to the object
> - implicitly called when a program terminates
> 
> 
> Just for fun, let's assume the 'unspecified' issue cannot be resolved. 
> Let's also assume there are dtors which expect to "clean up", and which 
> will fail when the dtor state is 'unspecified'.
> 
> What happens when a programmer forgets to explicitly delete such an 
> object? Well, the program is highly likely to fail (or be in an 
> inconsistent state) after the GC collects said object. This might be 
> before or during program termination.
> 
> How does one ensure this cannot occur? One obvious method would be for 
> the GC to /not/ invoke any dtor by default. While the GC would still 
> collect, such a change would ensure it cannot be the cause of a failing 
> program (it would also make the GC a little faster, but that's probably 
> beside the point).
> 
> Assuming that were the case, we're left with only the two cases where 
> cleanup is explicit and the dtor state is 'valid': via the delete 
> keyword, and via raii (both of which apply the same functionality).
> 
> This would tend to relieve the need for an explicit dispose() pattern, 
> since the dtor is now the equivalent?
> 
> 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.
> 
> What would be really nice is a tool to tell us about such leaks. It 
> should be possible for the GC (when configured to do so) to identify 
> collected objects which have a non-default dtor. In other words, the GC 
> can probably tell if a custom dtor is present (it has a different 
> address than a default dtor?). If the GC finds one of these during a 
> normal collection cycle, and is about to collect it, it might raise a 
> runtime error to indicate the leak instance?
> 
> Anyway ~ to summarize, this would have the following effect:
> 
> 1) no more bogus crashes due to dtors being invoked in an invalid state
> 2) no need for the dispose() pattern
> 3) normal collection does not invoke dtors, making it a little faster
> 4) there's a possibility of a tool to identify and capture leaking 
> resources. Something which would be handy anyway.
> 
> 
> For the sake of example: "unscoped" resources, such as connection-pools, 
> would operate per normal in this scenario: the pool elements should be 
> deleted explicitly by the hosting pool (or be treated as leaks, if they 
> have a custom dtor). The pool itself would have to be deleted explicitly 
> also ~ as is currently the case today ~ which can optionally be handled 
> via a module-dtor.
> 
> Thoughts?

All of those pros you mention are valid. But you'd have one serious con:
* Any class which required cleanup would have to be manually memory managed.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D