GC and dtors ~ a different approach?

kris foo at bar.com
Sun Apr 9 18:17:03 PDT 2006


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?



More information about the Digitalmars-d mailing list