From: Jon Harrop <jonathandeanharrop@googlemail.com>
To: <orbitz@ezabel.com>, <caml-list@inria.fr>
Subject: RE: [Caml-list] Scoped Bound Resource Management just for C++?
Date: Wed, 9 Feb 2011 18:03:11 -0000 [thread overview]
Message-ID: <045501cbc883$9e10c040$da3240c0$@com> (raw)
In-Reply-To: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com>
Orbitz 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.
>
> My questions are:
> 1) Do other people in the FP world consider this to be a good strategy?
For some kinds of resources under some circumstances, yes.
> 2) Can this be done in a sane way in a GCd language?
Yes, of course. You just use a higher order function to factor out the
pattern of initializing and cleaning up the resource. For example, the
following "file" function opens a file, applies the given function "f" to
the resulting channel and then closes the channel:
let file name f =
let ch = open_in name in
try
let x = f ch in
close_in ch;
x
with e ->
close_in ch
raise e
The OOP equivalent is called the command pattern. On the .NET platform, this
pattern is provided by the IDisposable interface and languages like C# and
F# even include syntactic support for it. This is used to handle resources
that benefit from deterministic cleanup, like file handles.
> 3) What are the alternatives in a language like Ocaml?
The most obvious alternative is to leave clean up to the garbage collector
by using a finalizer. When the resource is either memory or equivalent to
memory, this works extremely well in practice and is simpler than manual
memory management. For example, I once used the garbage collector to clean
up OpenGL display lists. However, this is not generally advised for
non-memory resources because they tend to be much more precious and,
therefore, prone to being exhausted.
Cheers,
Jon.
next prev parent reply other threads:[~2011-02-09 18:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-08 23:57 orbitz
2011-02-09 0:46 ` Guillaume Yziquel
2011-02-09 0:48 ` Jacques Garrigue
2011-02-09 6:25 ` dmitry grebeniuk
2011-02-09 12:01 ` rossberg
2011-02-09 15:15 ` orbitz
2011-02-09 16:14 ` Gerd Stolpmann
2011-02-09 16:52 ` David Rajchenbach-Teller
2011-02-09 17:54 ` orbitz
2011-02-09 21:50 ` Jon Harrop
2011-02-10 8:10 ` David Rajchenbach-Teller
2011-02-10 10:39 ` Guillaume Yziquel
2011-02-10 10:59 ` Guillaume Yziquel
2011-02-09 19:11 ` Florian Weimer
2011-02-09 20:10 ` Andreas Rossberg
2011-02-09 20:45 ` Florian Weimer
2011-02-09 21:12 ` Andreas Rossberg
2011-02-10 21:31 ` Florian Weimer
2011-02-09 18:03 ` Jon Harrop [this message]
2011-02-09 20:47 ` Norman Hardy
2011-02-09 21:00 ` Gabriel Scherer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='045501cbc883$9e10c040$da3240c0$@com' \
--to=jonathandeanharrop@googlemail.com \
--cc=caml-list@inria.fr \
--cc=orbitz@ezabel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox