Browse thread
exception safety / RAII ?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Oliver Bandel <oliver@f...> |
| Subject: | Re: [Caml-list] Re: exception safety / RAII |
On Wed, Mar 09, 2005 at 04:19:40PM +0000, Jon Harrop wrote: > On Wednesday 09 March 2005 14:48, you wrote: > > >> Very rarely having problems with something can't save it from being > > >> a very bad practice. Not explicitly closing your files is (in 99% of > > >> the cases) just sloppy coding. > > > > > > If we're talking about programs which are expected to run for an > > > arbitrary amount of time (servers, the top-level etc.) then yes. > > My statements were based on the incorrect assumption that the OCaml GC closes > files when it collects file handles. As this is not the case, I definitely > agree with you that not explicitly closing files in OCaml is sloppy coding > because they will not be closed implicitly. > > However, provided you don't need to make any guarantees about when the file is > closed during the running of the program, I still think that implicitly > closing a file (or deallocating an external resource) via the GC is not > sloppy coding. Indeed, this facility can be very useful and can eliminate an > important class of run-time errors. > > > This logic is routinely used in C to simply never call `free' because they > > only run for a short time. That's a textbook example of "sloppy coding". > > I wouldn't advocate never calling free() in a C program, but what is the > difference between calling free at some unspecified point in the future and > relying on a GC? I'm not a GC-expert, but it seems obvious to me, that a GC frees ressources at unspecified time and that also means at unspecified time in respect to the code that is executed. But calling a free() at a certain point in a program means that the deallocation is done at a certain time (in respect to code that is executed, even when not in certain real time in seconds). So, a free() in C is not unspecified, as it is called at a certain section of code. The GC frees ressources not as long as they are in use, but that they are not in use does not mean that they are *immediately* freed by the GC. It depends on statistical/stochastical things (not to determine). And that's the difference. To say a GC that it has to free ressources immediately, something like a GC-free-flush or something like that seems a littlebid like going back to free(). (Well, it's not the same, because the GC handles the "references" of which values are needed and which are not needed anymore, so a trigger to the GC to free ressources is not the same as writing code in C that does a free()-call. But normally it should be easier programming when the programmer does not necessarily have to think about freeing of GC-ressources.... normally the GC should be intelligent enough to handle it by itself.) (Rare cases may be there, where it is necessary to invoke GC-specific functions.) Ciao, Oliver