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 BBDDABC48 for ; Wed, 9 Mar 2005 16:35:22 +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 j29FZMvw009120 for ; Wed, 9 Mar 2005 16:35:22 +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 QAA17905 for ; Wed, 9 Mar 2005 16:35:21 +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 j29FZKAW009116 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 9 Mar 2005 16:35:21 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1D92y2-0006VU-Cn for caml-list@inria.fr; Wed, 09 Mar 2005 16:19:23 +0100 Received: from ottawa-hse-ppp4097345.sympatico.ca ([70.49.82.164]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Mar 2005 16:19:22 +0100 Received: from monnier by ottawa-hse-ppp4097345.sympatico.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Mar 2005 16:19:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Stefan Monnier Subject: Re: exception safety / RAII ? Date: Wed, 09 Mar 2005 10:05:26 -0500 Message-ID: <87u0nk98df.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> References: <293072a520e3724a0497e6456a8675be@mac.com> <877e9a1705030710476502ad31@mail.gmail.com> <1110281592.680.102.camel@localhost> <200503081828.44579.jon@jdh30.plus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ottawa-hse-ppp4097345.sympatico.ca User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:doY9sgsOPlEv1bdofM4vUXtMRzg= 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 422F17BA.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 422F17B9.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; umontreal:01 deallocated:01 afaik:01 verifiers:01 run-time:01 statically:01 deallocation:01 pointers:01 rework:01 api:01 minor:01 deallocation:01 ...:98 contrast:01 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: >> I'm not sure I understand Jon Harrop's concern about using resources >> after they've been deallocated. This has been addressed in the obvious >> way (return errors for operations on remaining references) in various >> languages for decades, and unlike memory management and type errors, >> AFAIK hasn't been a major source of bugs or complaints. > A great deal of effort has been put into writing static verifiers to ensure > correct use, in order to remove this class of run-time errors. So I think > this is unquestionably a source of bugs. There are different kinds of bugs. They can be common/rare, serious/benign, hard/easy to find, hard/easy to fix, ... Errors that have to do with things like "close" are generally easy to fix. It's important to catch them, so we have things like Vault that try to catch them statically. > Could it not be said that having a GC is a way to avoid such errors in the > context of memory allocation and deallocation? In contrast, errors that have to do with leakage and/or dangling pointers, are often hard to fix, requiring a considerable rework of the code. Having a GC gives you a freedom when designing an API that is completely incomparable to the minor convenience of not having to explicitly close files. Compare the success of C++ destructors to deal with file-closing and the insufficiency of those same destructors to deal with object deallocation (leading to the never ending use of reference counting and/or explicit copying). Stefan