From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA17592; Wed, 11 Dec 2002 20:47:44 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA17099 for ; Wed, 11 Dec 2002 20:47:43 +0100 (MET) Received: from epexch01.qlogic.org ([63.170.40.3]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id gBBJlgX05352 for ; Wed, 11 Dec 2002 20:47:42 +0100 (MET) Received: from epmailtmp.qlogic.org ([10.20.33.254]) by epexch01.qlogic.org with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Dec 2002 13:46:38 -0600 Received: from [10.20.33.146] ([10.20.33.146]) by epmailtmp.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Wed, 11 Dec 2002 13:46:38 -0600 Date: Wed, 11 Dec 2002 13:55:10 -0600 (CST) From: Brian Hurt X-X-Sender: Reply-To: Brian Hurt To: Blair Zajac cc: Caml Users Mailing List Subject: Re: [Caml-list] Resource acquisition is initialization In-Reply-To: <3DF78FB5.A1642B8@orcaware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 11 Dec 2002 19:46:38.0332 (UTC) FILETIME=[0501CBC0:01C2A14E] Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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