From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 9DA73BC32 for ; Thu, 10 Mar 2005 15:36:11 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j2AEaBgL007635 for ; Thu, 10 Mar 2005 15:36:11 +0100 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 PAA22479 for ; Thu, 10 Mar 2005 15:36:10 +0100 (MET) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j2AEa9sP007625 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 10 Mar 2005 15:36:10 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1D9Ojp-0002ZV-TR for caml-list@inria.fr; Thu, 10 Mar 2005 15:34:09 +0100 Received: from hse-quebeccity-ppp3500928.sympatico.ca ([65.92.241.52]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Mar 2005 15:34:09 +0100 Received: from monnier by hse-quebeccity-ppp3500928.sympatico.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Mar 2005 15:34:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Stefan Monnier Subject: Re: exception safety / RAII ? Date: Thu, 10 Mar 2005 09:33:38 -0500 Message-ID: <871xan7f9q.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> References: <293072a520e3724a0497e6456a8675be@mac.com> <200503071710.52544.jon@jdh30.plus.com> <87zmxc99g5.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> <200503091619.40419.jon@ffconsultancy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: hse-quebeccity-ppp3500928.sympatico.ca User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:Jox9TQJTFt+tbo/LGRUe2On5fwY= Sender: news X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gclci-caml-list@m.gmane.org X-MailScanner-To: caml-list@inria.fr X-Miltered: at concorde with ID 42305B5B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 42305B59.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; umontreal:01 ocaml:01 ocaml:01 implicitly:01 implicitly:01 run-time:01 runtime:01 unspecified:01 pointer:01 trivial:01 finalizers:01 finalizers:01 stays:98 circumstance:98 exception:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: > My statements were based on the incorrect assumption that the OCaml GC > closes files when it collects file handles. As this is not the case, > I definitely agree with you that not explicitly closing files in OCaml is > sloppy coding because they will not be closed implicitly. My argument stays the same either way. > However, provided you don't need to make any guarantees about when the > file is closed during the running of the program, I still think that > implicitly closing a file (or deallocating an external resource) via the > GC is not sloppy coding. Indeed, this facility can be very useful and can > eliminate an important class of run-time errors. Can you give examples where it's useful? I don't consider "not needing to call `close' on line NNNN of my code" to be useful. Can you describe the "important class of runtime errors" that would be supposedly eliminated? >> This logic is routinely used in C to simply never call `free' because they >> only run for a short time. That's a textbook example of "sloppy coding". > I wouldn't advocate never calling free() in a C program, but what is the > difference between calling free at some unspecified point in the future and > relying on a GC? When you rely on a GC, you don't need to keep the pointer around somewhere in order to be able to call "free" on it and you don't have to keep track of who might still be using the object. This means that a library for a collection data structure can have a very different interface since it doesn't have to worry about ownership of the contents of the data structure. >> It's extremely rare that the point in the code where a file can be closed >> is not trivial to find. > In the case of files, yes. More generally, this can be applied to all > sorts of external resources where that is not true. Might be: there's no way we can generalize. I'm talking about files here. Finalizers are great, but they shouldn't be used for files. I'd also argue that they generally shouldn't be used for any "external resource". Though I wouldn't be surprised if there's a counter example somewhere where I'd agree that finalizers are good solution for the management of some particular kind of external resource in some particular circumstance. Stefan