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 C45E2BC84 for ; Wed, 9 Mar 2005 17:18:46 +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 j29GIklt014959 for ; Wed, 9 Mar 2005 17:18:46 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA19336 for ; Wed, 9 Mar 2005 17:18:46 +0100 (MET) Received: from ptb-relay02.plus.net (ptb-relay02.plus.net [212.159.14.213]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j29GIjhi005757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Mar 2005 17:18:45 +0100 Received: from [80.229.56.224] (helo=chetara) by ptb-relay02.plus.net with esmtp (Exim) id 1D93tQ-0000zk-T5 for caml-list@inria.fr; Wed, 09 Mar 2005 16:18:41 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@inria.fr Subject: Re: [Caml-list] Re: exception safety / RAII ? Date: Wed, 9 Mar 2005 16:19:40 +0000 User-Agent: KMail/1.7.1 References: <293072a520e3724a0497e6456a8675be@mac.com> <200503071710.52544.jon@jdh30.plus.com> <87zmxc99g5.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> In-Reply-To: <87zmxc99g5.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503091619.40419.jon@ffconsultancy.com> X-Miltered: at concorde with ID 422F21E6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 422F21E5.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 ocaml:01 implicitly:01 implicitly:01 run-time:01 unspecified:01 trivial:01 48,:98 frog:98 wrote:01 exception:01 arbitrary:01 short:01 explicitly: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: On Wednesday 09 March 2005 14:48, you wrote: > >> Very rarely having problems with something can't save it from being > >> a very bad practice. Not explicitly closing your files is (in 99% of > >> the cases) just sloppy coding. > > > > If we're talking about programs which are expected to run for an > > arbitrary amount of time (servers, the top-level etc.) then yes. 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. 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. > 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? > 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. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists