Destructor semantics

[Steven Schveighoffer]

On Thu, 12 Aug 2010 16:08:17 -0400, Don <nospam at nospam.com> wrote:

> Steven Schveighoffer wrote:
>> On Thu, 12 Aug 2010 13:05:53 -0400, Joe Greer <jgreer at doubletake.com>  
>> wrote:
>>
>>> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in
>>> news:op.vhbtwjhoeav7ka at localhost.localdomain:
>>>
>>>>> 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?
>
> That's the only example of an nearly unlimited resource which I've heard  
> thus far, but that raises the question, why the hell would you be using  
> malloc if you're not going to free it, when you have a language with a  
> gc? Effectively, the gc is freeing your malloced memory.

malloc/free is a lot more efficient than the GC.  Partly on account of it  
being so mature, and partly because it doesn't have to deal with GC-like  
problems.

Kris of Tango made an allocator for tango.container that is extremely fast  
based on malloc/free, but you are required to use it only for pure value  
types (no references).

Another reason is to be able to use it in the finalizer, since malloc'd  
memory will be valid.  If, for instance, you registered some object with a  
name, you need to have a malloc'd copy of the name to be able to  
unregister it on finalization.

Finally, if the 3rd party library your using gives you malloc'd data, what  
do you do then?

>> That's a possible solution.  I just don't like the blanket assumptions  
>> being made.
>
> Actually it's the absence of a use case.
>
> Hypothesis: if a finalizer is run, where it actually DOES something (as  
> opposed to, for example, running a pile of asserts), there's always a  
> bug.
>
> It's an extreme hypothesis, so it should be really easy to disprove.
> Can you come up with a counterexample?

Isn't it a bug to rely on finalization to tell you something is wrong with  
your program?  Essentially, if an object is finalized, and it must close  
resources, you have two options: close the resources and continue silently  
or loudly alert the user that there is a programming bug.  Considering  
that finalization is not guaranteed, that raises significantly the  
potential of bugs escaping into shipping code because the "bad" case just  
didn't get triggered.  I'd say in most cases, the bad case isn't so bad.

What if a finalizer asserted things were closed, and then closed them if  
they weren't.  That way, you get asserts when not compiling in release  
mode, and in release mode, the program soldiers on as best it can without  
throwing seemingly random errors.  It's just a thought.  I don't like the  
idea of throwing errors in the finalizer, because the error report can  
possibly be completey decoupled from the source.

For an example, Tango manages all I/O with classes, and I've written code  
that could run indefinitely opening and closing files continuously.  I  
never ran into resource problems.  If all of a sudden it started  
complaining that I wasn't closing the files, I'd question why someone put  
in that change, since it was working fine before.  I agree that the GC is  
not the best place to rely on closing files, but it doesn't *hurt* to  
close resources when you realize the last reference to that resource is  
about to be eliminated.

-Steve