On Thu, 12 Aug 2010 13:05:53 -0400, Joe Greer <[email protected]>
wrote:
"Steven Schveighoffer" <[email protected]> wrote in
news:[email protected]:
Logically speaking if an object isn't destructed, then it lives
forever and if it continues to hold it's resource, then we have a
programming error. The GC is for reclaiming memory, not files. It
can take a long time for a GC to reclaim an object and you surely
don't want a file locked for that long anymore than you want it held
open forever. My point is, that it is a programming error to expect
the GC be involved in reclaiming anything but memory. IMO, the best
use of a finalizer is to error out if an object holding a resource
hasn't been destructed, because there is obviously a programming
error here and something has leaked. GCs aren't there to support
sloppy programming. They are there to make your life easier and
safer.
An open file maybe, but why should the compiler decide the severity of
not closing the resource? What if the resource is just some
C-malloc'd memory?
Note, you are free to write your finalizer to do exactly what you want
(print some error if it's called and the file's still open). I just
don't think the compiler should be involved in the decision, because
it's too ill-equipped to make one.
-Steve
I think you misunderstand what I was saying. The compiler doesn't decide
any of that. The programmer conserned with correctness has the option of
making his finalizer complain about unfreed resources. I language
shouldn't be your nanny, but it should encourage and enable you to do the
right thing. There is just no substitute for knowing how to program.
So you mark a struct something like:
@noheap struct File
{...}
That's a possible solution. I just don't like the blanket assumptions
being made.
-Steve
