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 p19HsHHa004459 for ; Wed, 9 Feb 2011 18:54:17 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYBAHhjUk3RVdivkGdsb2JhbAClQAgWAQEBCQkMBxEEIKIZmgmFXASEf4ZxiDU6 X-IronPort-AV: E=Sophos;i="4.60,446,1291590000"; d="scan'208";a="87743258" Received: from mail-qy0-f175.google.com ([209.85.216.175]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 09 Feb 2011 18:54:11 +0100 Received: by qyk8 with SMTP id 8so1486284qyk.6 for ; Wed, 09 Feb 2011 09:54:10 -0800 (PST) Received: by 10.224.47.80 with SMTP id m16mr4087938qaf.165.1297274050227; Wed, 09 Feb 2011 09:54:10 -0800 (PST) Received: from osx.som.umaryland.edu ([134.192.133.107]) by mx.google.com with ESMTPS id q12sm333145qcu.30.2011.02.09.09.54.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 09:54:09 -0800 (PST) Cc: Gerd Stolpmann , rossberg@mpi-sws.org, caml-list@inria.fr Message-Id: <25000DA4-042A-437D-8082-10C70E1C740F@ezabel.com> From: orbitz@ezabel.com To: David Rajchenbach-Teller In-Reply-To: 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 12:54:07 -0500 References: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com> <77df810e993b3002f8b97622102da8dd.squirrel@mail.mpi-sws.org> <1297268092.24058.416.camel@thinkpad> X-Mailer: Apple Mail (2.936) Subject: Re: [Caml-list] Scoped Bound Resource Management just for C++? Do they appear in C++? I would a dtor takes care of that for you when it comes to streams. On Feb 9, 2011, at 11:52 AM, David Rajchenbach-Teller wrote: > 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. >