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 69BD2BC32 for ; Mon, 7 Mar 2005 01:02:52 +0100 (CET) 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 j2702oee030753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Mar 2005 01:02:51 +0100 Received: from [80.229.56.224] (helo=chetara) by ptb-relay02.plus.net with esmtp (Exim) id 1D85hy-00056L-6r for caml-list@yquem.inria.fr; Mon, 07 Mar 2005 00:02:50 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] exception safety / RAII ? Date: Mon, 7 Mar 2005 00:03:52 +0000 User-Agent: KMail/1.7.1 References: <293072a520e3724a0497e6456a8675be@mac.com> In-Reply-To: <293072a520e3724a0497e6456a8675be@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503070003.52747.jon@jdh30.plus.com> X-Miltered: at nez-perce with ID 422B9A2A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 ocaml:01 deallocated:01 garbage:01 garbage:01 deallocated:01 elegantly:01 frog:98 wrote:01 exception:01 exception:01 iterators:01 exceptions:01 exceptions: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 Saturday 05 March 2005 18:16, Michael Benfield wrote: > I'm looking at OCaml coming from sort of a C++ background and I'm > finding it really exciting. Yes, it is an excellent language, far better than C++ for virtually all tasks. I do suggest that you try to shed most of the C++ ways of thinking though, as the vast majority of them do not apply to OCaml. In particular, forget about iterators and OOP. > There's one thing that worries me though. C++ programmers have been > dealing with issues of exception safety for years - it's a complicated > problem because coding in the presence of exceptions for all intents > and purposes means your function could end at any point, so how can you > make sure resources are deallocated? This is only a complicated problem if you do not have a garbage collector, which OCaml does. > The C++ solution to this problem > is a technique called Resource Acquisition Is Initialization. This is a poor man's alternative to garbage collection. The principal problem is the inability to determine what object owns which resources at any given point in the code. > C++ > objects have destructors, which are simply functions that will always > be called on exit from a scope - including if the exit is caused by an > exception coming up through your function. You make resource release > (whether the resource is memory, a socket, whatever) happen in a > destructor, and then you are set. This is very handy even disregarding > exceptions. In OCaml, any internal resources are transparently deallocated by the garbage collector so you do not need to worry. In the relatively unlikely event of an external resource, you can either explicitly deallocate yourself or you can wrap the resource in an OCaml object and set the finaliser of the object to deallocate the resource for you. In theory, this could take forever to deallocate. In practice, resources are deallocated extremely quickly. > So I'm just wondering what facilities OCaml has to either implement > this concept, or other concepts to help with exception safety? The > OCaml manual says: "Also, finalization can be performed by trapping all > exceptions, performing the finalization, then raising again the > exception". This makes me cringe. This can be done much more elegantly in OCaml than in C++. Do you know how this is done in OCaml? In most cases you probably won't care when a file is closed after writing to it, so you can just rely on the garbage collector. In the few cases that you do mind, this is neither difficult nor complicated to implement. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists