On Wed, 11 Dec 2002, Blair Zajac wrote:

> One of the nice things about C++ and Java is that with properly
> designed classes, you don't need to worry about freeing resources
> in complicated code, because the when the objects go out of scope
> either normally or via an exception, they will clean themselves up.
> 
> Here's a good description of this idiom:
> 
> http://sourceforge.net/docman/display_doc.php?docid=8673&group_id=9028

I didn't think you could allocate objects on the stack in Java 
(fundamental types, like ints and booleans, yes- but not objects).

There are three problems I have with this idea.  The first problem is that
it greatly complicates exception handling, as now the exceptions have to
call destructors for all the objects on the stack as they pop the stack
frames off.  The second problem I have with this is what happens when an
object goes out of scope in it's original context, but isn't yet garbage?  
We've all seen C code like:

char * foo(...) {
    char buf[];
    /* do something to fill buf */
    return buf;
}

This sounds like a wonderful way to introduce dangling pointer bugs in the 
language.

Third, I question how usefull this idea is.  OK, so the resource doesn't 
get cleaned up the nanosecond it becomes garbage.  In most cases, this 
isn't a problem- for example, file handlers.  The fact that you have a 
couple of extra, garbage, filehandles open and not yet collected won't 
really hurt much of anything, so long as they get collected (and closed) 
eventually.  Most file objects come with an explicit close option, so even 
if you, for some unknown reason, write code that just sits in a tight loop 
opening files, you can close them just as fast and not leave lots of spare 
file descriptors open.  And Java provides a function to force a garbage 
collection, I beleive Ocaml does as well (in pervasives?  I'm still 
learning the language).

The only thing I can think of which cannot tolerate the cleanup slop is 
releasing a mutex.  Deleting the mutex itself is a good application for 
GC, unlocking the mutex is not.  And for that, I think representing 
holding the lock as the lifetime of an object to be a bad idea.  Were Caml 
interested more in doing multithreaded code, I'd recommend something like 
Java's synchronize keyword.

Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners