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 9FDCDBC84 for ; Sat, 12 Mar 2005 23:55:02 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2CMt1M4026583 for ; Sat, 12 Mar 2005 23:55:01 +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 XAA15338 for ; Sat, 12 Mar 2005 23:55:01 +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 j2CMt0Oe022291 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 12 Mar 2005 23:55:00 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DAFUR-0007CJ-NY for caml-list@inria.fr; Sat, 12 Mar 2005 23:53:47 +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 ; Sat, 12 Mar 2005 23:53:47 +0100 Received: from monnier by hse-quebeccity-ppp3500928.sympatico.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 12 Mar 2005 23:53:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Stefan Monnier Subject: Re: exception safety / RAII ? Date: Sat, 12 Mar 2005 17:54:24 -0500 Message-ID: <87ekekeb9g.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> References: <293072a520e3724a0497e6456a8675be@mac.com> <200503091619.40419.jon@ffconsultancy.com> <871xan7f9q.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> <200503101652.01848.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:Mex1Rf4mKbkbkKgLeqZ/kz8oUJw= 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 nez-perce with ID 42337345.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 42337344.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; umontreal:01 implicitly:01 run-time:01 afaict:01 runtime:01 incorrectly:01 runtime:01 finalizers:01 finalizers:01 finalizer:01 destroyed:98 circumstance:98 exception:01 short:01 behaviour: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: >> > 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. Two problems with this example: it doesn't involve files AFAICT, and it's not an example in any useful sense. You'd need to describe the skeleton of the code to explain why it's useful (rather than merely convenient). >> 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. [ Ignoring the fact that it still doesn't seem to involve files ] Are such errors common (or difficult to diagnose/fix) enough that they deserve the name "important class of runtime errors"? (genuine question: I know next to nothing about OpenGL). >> > 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. You're arguing beside my point: I don't care whether there are cases where using finalizers to close files doesn't hurt. My point is both that there are cases where they do hurt (even sometimes for the exact same code where they didn't hurt in other circumstances), and that the added convenience of not needing to explicitly close the file is insignificant. So I'd like to see an example where the lack of a "file-close finalizer" would make the code harder to write. >> 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? I've already replied to this and even gave another example (CPU), so please try something else. Stefan