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 p1A8AIlt009368 for ; Thu, 10 Feb 2011 09:10:18 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggGAKssU03Cpx5ei2dsb2JhbACXTo4dFQEBAQoLChgkulyFXASPKw X-IronPort-AV: E=Sophos;i="4.60,451,1291590000"; d="scan'208";a="99612777" Received: from sucre.univ-orleans.fr ([194.167.30.94]) by mail1-smtp-roc.national.inria.fr with ESMTP; 10 Feb 2011 09:10:12 +0100 Received: from localhost (localhost [127.0.0.1]) by sucre.univ-orleans.fr (Postfix) with ESMTP id 8A3B894420; Thu, 10 Feb 2011 09:10:12 +0100 (CET) Received: from sucre.univ-orleans.fr ([127.0.0.1]) by localhost (sucre.univ-orleans.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gmerv--TRJl; Thu, 10 Feb 2011 09:10:12 +0100 (CET) Received: from smtps.univ-orleans.fr (smtps.univ-orleans.fr [194.167.30.152]) by sucre.univ-orleans.fr (Postfix) with ESMTP id 6FB039438A; Thu, 10 Feb 2011 09:10:12 +0100 (CET) Received: from [192.168.0.11] (dau94-10-88-189-211-192.fbx.proxad.net [88.189.211.192]) by smtps.univ-orleans.fr (Postfix) with ESMTP id E226C36E60; Thu, 10 Feb 2011 09:10:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Rajchenbach-Teller In-Reply-To: <25000DA4-042A-437D-8082-10C70E1C740F@ezabel.com> Date: Thu, 10 Feb 2011 09:10:11 +0100 Cc: Gerd Stolpmann , rossberg@mpi-sws.org, caml-list@inria.fr Message-Id: References: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com> <77df810e993b3002f8b97622102da8dd.squirrel@mail.mpi-sws.org> <1297268092.24058.416.camel@thinkpad> <25000DA4-042A-437D-8082-10C70E1C740F@ezabel.com> To: orbitz@ezabel.com X-Mailer: Apple Mail (2.1082) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p1A8AIlt009368 Subject: Re: [Caml-list] Scoped Bound Resource Management just for C++? Well, that depends -- keep in mind that I'm discussing one specific instance, that of closing streams and ensuring that they are correctly flushed, in the right order. * users manually closing the stream keeping things safe is essentially the same issue in OCaml and C++; * downstream stream being closed keeping things safe is essentially the same issue in OCaml and C++, but the garbage-collector does make things easier in OCaml; * garbage-collection/deallocation Probably easier in C++, as long as you keep to the small subset of C++ in which users discipline themselves to simple resource allocation/finalization idioms. Suddenly much harder if your users can heap-allocate or pass by reference for the purpose of sharing between distinct scopes (which, in my experience, is the kind of thing you want to do as soon as your library is powerful enough). * abrupt (but non-segfault) termination of the program, say a thread killing the whole process Now, I'm not sure how one would implement this in C++. I tend to believe it's easier in OCaml, as judicious use of [at_exit] and weak references lets you register behaviors that will only be triggered if garbage-collection hasn't taken place by the time the program exits. Now, of course, we touch another issue: the way I see it, C++ is not just one language, but a whole collection of languages with interoperability. Things that make perfect sense and are completely safe if you limit yourself to some idioms suddenly become the stuff of segfaultish nightmares if you attempt to integrate them in a project which has been written with a distinct set of axioms. I'd call this a clear win by OCaml :) Cheers, David On Feb 9, 2011, at 6:54 PM, orbitz@ezabel.com wrote: > Do they appear in C++? I would a dtor takes care of that for you when it comes to streams.