From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p19FFpGH030063 for ; Wed, 9 Feb 2011 16:15:51 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqABAMc+Uk3RVdi2k2dsb2JhbACXKI4UCBUBAQEBCQkKCREEIKI5mW+FXASEf4ZxiDU6 X-IronPort-AV: E=Sophos;i="4.60,446,1291590000"; d="scan'208";a="99574489" Received: from mail-qy0-f182.google.com ([209.85.216.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 09 Feb 2011 16:15:45 +0100 Received: by qyk36 with SMTP id 36so193538qyk.6 for ; Wed, 09 Feb 2011 07:15:44 -0800 (PST) Received: by 10.224.41.8 with SMTP id m8mr16729290qae.161.1297264544243; Wed, 09 Feb 2011 07:15:44 -0800 (PST) Received: from osx.som.umaryland.edu ([134.192.133.107]) by mx.google.com with ESMTPS id y17sm232516qci.21.2011.02.09.07.15.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 07:15:42 -0800 (PST) From: orbitz@ezabel.com To: rossberg@mpi-sws.org In-Reply-To: <77df810e993b3002f8b97622102da8dd.squirrel@mail.mpi-sws.org> X-Priority: 3 (Normal) References: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com> <77df810e993b3002f8b97622102da8dd.squirrel@mail.mpi-sws.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Feb 2011 10:15:43 -0500 Cc: caml-list@inria.fr X-Mailer: Apple Mail (2.936) Subject: Re: [Caml-list] Scoped Bound Resource Management just for C++? Thanks for the answers everyone. How does one safely write code in Ocaml that guarantees resources will be freed? Guillaume mentioned the with-idiom, but even that doesn't seem entirely safe. On Feb 9, 2011, at 7:01 AM, rossberg@mpi-sws.org wrote: >> One of the benefits, in my opinion, of C++ is SBRM. You can reason >> about the lifetime of an object and have an give yourself guarantees >> about its clean up. The method of initialization and clean up are >> also consistent for every object in the language. > > Don't believe the hype. :) Scope-bound resource management is > inherently > broken, at least without sophisticated type system support. In a > higher-order language, there are various ways in which objects could > escape > their scope, e.g. closures, references, exceptions. That can only > mean one > of two things for SBRM: > > 1) Either it is not actually true, i.e. life times are not actually > bound by > scope in general and you have no actual guarantees, > > 2) or it is unsafe, i.e. you can access an object after its life > time has > ended, with potentially desastrous effects. > > C++ chose (2), which is out of the question for a safe language. If > your > language makes heavy use of first-class functions (and thus > closures) that > strategy is a particular no-go. > > Also, SBRM does not scale at all to concurrency. The underlying > assumption > that all life times are somehow well-bracketed through the dynamic > calling > hierarchy simply doesn't hold anymore when you have shared-state > concurrency. Getting life times right in concurrent C++ is a > nightmare in my > experience, and often requires synchronizing deallocation in quite > inefficient ways (thereby effectively making it explicit, and > subverting the > whole idea of tying it to scope implicitly). > > /Andreas >