Destructor semantics

[Michel Fortin]

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

> 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.
> 
> I can think of a couple of reasons for using malloc, but finalisers 
> aren't a good solution to any of them.

For one thing, you could ask Andrei why he based std.containers.Array 
on malloc/free with a reference counter. Not being able to use Array as 
a member of a class would be quite drastic.


> 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?

Here is a real-world example: the D/Objective-C bridge use a class 
destructor/finalizer to release the Objective-C counterpart of a 
wrapper (by calling the release method on the Objective-C object). The 
Objective-C object is not something I can allocate with the D GC, and 
the D counterpart wouldn't be very usable if it was not managed by the 
D GC. So finalization does the cleanup, and that works just fine.

I wonder what QtD does, but it's probably something similar too.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/