From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p19GqTcQ002473 for ; Wed, 9 Feb 2011 17:52:30 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkEANJUUk3Cpx5ei2dsb2JhbAClRBUBAQEKCwoYJLxChVwEjyIa X-IronPort-AV: E=Sophos;i="4.60,446,1291590000"; d="scan'208";a="75644338" Received: from sucre.univ-orleans.fr ([194.167.30.94]) by mail3-smtp-sop.national.inria.fr with ESMTP; 09 Feb 2011 17:52:24 +0100 Received: from localhost (localhost [127.0.0.1]) by sucre.univ-orleans.fr (Postfix) with ESMTP id CF89494457; Wed, 9 Feb 2011 17:52:24 +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 HJ6NFEqR5JuQ; Wed, 9 Feb 2011 17:52:24 +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 A5BF3943B7; Wed, 9 Feb 2011 17:52:24 +0100 (CET) Received: from [192.168.1.100] (unknown [213.144.210.93]) by smtps.univ-orleans.fr (Postfix) with ESMTP id 3B20736E62; Wed, 9 Feb 2011 17:52:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Rajchenbach-Teller In-Reply-To: <1297268092.24058.416.camel@thinkpad> Date: Wed, 9 Feb 2011 17:52:23 +0100 Cc: orbitz@ezabel.com, 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> To: Gerd Stolpmann X-Mailer: Apple Mail (2.1082) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p19GqTcQ002473 Subject: Re: [Caml-list] Scoped Bound Resource Management just for C++? Actually, in Batteries, we have to go through a number of hoops to be absolutely certain that a stream is flushed before we quit the application. We have to interact with: - users manually closing the stream; - any of the downstream streams being closed for any reason; - finalization; - the programmer exiting the program with [exit]; - the user exiting the program with [Ctrl-C]; - ... Of course, the same issues appear in C++. Cheers, David On Feb 9, 2011, at 5:14 PM, Gerd Stolpmann wrote: > Am Mittwoch, den 09.02.2011, 10:15 -0500 schrieb orbitz@ezabel.com: >> 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. > > You mean C++ is safer in this respect? > > Come on. Fully automatic memory management as in Ocaml is certainly > safer than any semi-automatic scheme. It will find all memory blocks > that are not referenced anymore. It's guaranteed. It works even with > circular structures (this is not a boy GC). > > You would use "with" only for cases where non-memory resources are > referenced, like file descriptors. And you have to close files in C++, > too. If you want to be very careful here, you can even set a finaliser > that emits a warning when you forgot to close a descriptor (but you have > then to remember whether you closed it), like in > > type managed_fd = > { fd : Unix.file_descr; > mutable fd_closed : bool > } > > (* after opening the file: *) > let mfd = { fd=fd; fd_closed=false } > > (* Attach the finaliser: *) > let mfd_fin mfd = > if not mfd.fd_closed then > prerr_endline "Hey, there is a forgotten file descriptor" > Gc.finalise mfd_fin mfd > > (* Use mfd as in - ensure you always pass mfd around: *) > Unix.read mfd.fd ... > > (* When you close: *) > Unix.close mfd.fd; > mfd.fd_closed <- true > > I wouldn't recommend to close fd in mfd_fin, because fd might not be a > simple file, and you can trigger any kind of external activity by > closing it. > > I've written a number of 24/7 server programs in Ocaml now, and I can > tell you, resource management is easy. You can usually skip the "search > for memory leaks" step before deploying to production.