* files & handlers...
@ 2000-02-05 10:37 Benoit de Boursetty
2000-02-07 15:23 ` Stefan Monnier
2000-02-07 15:46 ` Markus Mottl
0 siblings, 2 replies; 3+ messages in thread
From: Benoit de Boursetty @ 2000-02-05 10:37 UTC (permalink / raw)
To: caml-list
Hi,
Here is a naive, user-point-of-view question!
I think we all find the ML language is not tailored to handle file
accesses as they were implemented in current systems, don't we? All of us
wrote some day the following code:
let f = open_in filename in
let temp = input_line f in
close f;
temp;;
And if you write this:
let f = open_in filename in input_line f;;
(which is more natural to me)
you can never close the file you've opened.
What would the language have to support in order that opened files be
automatically closed when they get out of reach from the program? Is it
what is called "finalization"?
Thanks for your help
Benoit de Boursetty
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: files & handlers...
2000-02-05 10:37 files & handlers Benoit de Boursetty
@ 2000-02-07 15:23 ` Stefan Monnier
2000-02-07 15:46 ` Markus Mottl
1 sibling, 0 replies; 3+ messages in thread
From: Stefan Monnier @ 2000-02-07 15:23 UTC (permalink / raw)
To: caml-list
>>>>> "Benoit" == Benoit de Boursetty <debourse@email.enst.fr> writes:
> And if you write this:
> let f = open_in filename in input_line f;;
> (which is more natural to me)
> you can never close the file you've opened.
> What would the language have to support in order that opened files be
> automatically closed when they get out of reach from the program? Is it
> what is called "finalization"?
Yes, but it should be avoided if possible because of several
restrictions in its semantics. For most uses a construct such as
with_file <name>
(fn f => <body>)
will work just as well but with the guarantee that the file will be
closed at a well specified time.
Stefan "obviously not familiar enough with Caml's syntax"
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: files & handlers...
2000-02-05 10:37 files & handlers Benoit de Boursetty
2000-02-07 15:23 ` Stefan Monnier
@ 2000-02-07 15:46 ` Markus Mottl
1 sibling, 0 replies; 3+ messages in thread
From: Markus Mottl @ 2000-02-07 15:46 UTC (permalink / raw)
To: Benoit de Boursetty; +Cc: OCAML
> What would the language have to support in order that opened files be
> automatically closed when they get out of reach from the program? Is it
> what is called "finalization"?
Yes, this would be one solution. However, there are some drawbacks to using
finalization. In fact, even the "destructor-oriented" approach in C++
suffers from this deficiency: it is possible that the file/socket/whatever
is only closed at a much later point of time than expected.
For example, there might be a long running loop between the call to the
destructor (or lots of computation without GC-triggering allocation) before
the file is closed again.
If you want to make sure that closing happens immediately after the desired
operation, you will either have to state so explicitely (inconvenient) or
use a "higher-order" trick:
let do_file name f =
let file = open_in name in
f file;
close_in file
Then you can write something like:
do_file "foo" (fun file -> ...)
and the file will be closed again.
If you happen to use the PCRE-library (Perl Compatibility Regular
Expression) for OCaml, there are two useful functions for such things,
namely "foreach_file" and "foreach_line".
E.g.:
open Pcre
let _ =
foreach_file ["foo"; "bar"] (fun (name, file) ->
print_endline ("Processing: " ^ name);
foreach_line in: file (fun line ->
print_endline ("line: " ^ line)
)
)
Using this, you cannot forget to close files again.
Best regards,
Markus Mottl
--
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-02-08 8:46 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-02-05 10:37 files & handlers Benoit de Boursetty
2000-02-07 15:23 ` Stefan Monnier
2000-02-07 15:46 ` Markus Mottl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).