From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id C7998BC32 for ; Thu, 10 Mar 2005 18:10:26 +0100 (CET) Received: from ptb-relay03.plus.net (ptb-relay03.plus.net [212.159.14.214]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2AHAQHK009531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Mar 2005 18:10:26 +0100 Received: from [80.229.56.224] (helo=chetara) by ptb-relay03.plus.net with esmtp (Exim) id 1D9RB3-0006mo-1A for caml-list@yquem.inria.fr; Thu, 10 Mar 2005 17:10:25 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: exception safety / RAII ? Date: Thu, 10 Mar 2005 16:52:01 +0000 User-Agent: KMail/1.7.1 References: <293072a520e3724a0497e6456a8675be@mac.com> <200503091619.40419.jon@ffconsultancy.com> <871xan7f9q.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> In-Reply-To: <871xan7f9q.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: <200503101652.01848.jon@ffconsultancy.com> X-Miltered: at nez-perce with ID 42307F82.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 implicitly:01 run-time:01 runtime:01 incorrectly:01 arbitrarily:01 ocaml:01 segfault:01 finalizers:01 finalizers:01 ocaml:01 destroyed:98 circumstance:98 ...:98 frog:98 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 Thursday 10 March 2005 14:33, Stefan Monnier wrote: > > 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. OpenGL display lists from earlier in this thread. > Can you describe the "important class of runtime errors" that would be > supposedly eliminated? In that case, undefined rendering behaviour when a display list is executed after it has been incorrectly destroyed. This could also wreck the OpenGL state and break rendering for the rest of the frame or even for the rest of the program. Unless you go to great lengths to catch such errors in all cases (which could require arbitrarily complicated tests, slowing down your program) such mistakes could make an OCaml program segfault with more fragile external resources. > > 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. Let me try another file-specific example then: Programs which save output at some point during their execution. From the users point of view, there is no "visible" difference between having the program close the file as soon as writing is complete and leaving it up to the GC to close the file a short time afterwards (and before it completes). I have many such programs. > 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. Even if the external resource is memory? Generally, I'd always consider exploiting the GC because of the safety it provides... -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists