From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p19C26Z2021172 for ; Wed, 9 Feb 2011 13:02:06 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAFgRUk2LEwExhWdsb2JhbACXKI4xAQEBCgsKGAUfrlQBjUEFhVyLdA X-IronPort-AV: E=Sophos;i="4.60,446,1291590000"; d="scan'208";a="87719192" Received: from infao0809.mpi-sb.mpg.de (HELO hera.mpi-sb.mpg.de) ([139.19.1.49]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 09 Feb 2011 13:02:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Message-ID:In-Reply-To: References:Date:Subject:From:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=t3hC0RMGz3fgTjvvm0GG9d1NiQsfncycR3 gPsUim7Hg=; b=Dnk01Wx4h9jcABf8v++7Re8ztKHk78U1QivCEGnOPldYelKIoG ZEe0jhGpFx9CQlslt6RUM9wRY1tZAqoTwe8f5JS1bejgMoriFUdOzVn0Ilfdvm9H 55DtHAFOVrCQuoEvyMRmIRdPUTGNYXOIyplFaTqFwBg1LBxeapGd2MocQ= Received: from zak.mpi-klsb.mpg.de ([139.19.1.27]:57685) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1Pn8kA-0002KR-Lj; Wed, 09 Feb 2011 13:02:01 +0100 Received: from local by zak.mpi-klsb.mpg.de (envelope-from ) with local (Exim 4.69) id 1Pn8kA-0004QJ-50; Wed, 09 Feb 2011 13:01:58 +0100 Received: from 74.125.57.233 (SquirrelMail authenticated user rossberg) by mail.mpi-sws.org with HTTP; Wed, 9 Feb 2011 13:01:58 +0100 (CET) Message-ID: <77df810e993b3002f8b97622102da8dd.squirrel@mail.mpi-sws.org> In-Reply-To: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com> References: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com> Date: Wed, 9 Feb 2011 13:01:58 +0100 (CET) From: rossberg@mpi-sws.org To: orbitz@ezabel.com Cc: caml-list@inria.fr User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [Caml-list] Scoped Bound Resource Management just for C++? > 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