POV-Ray : Newsgroups : povray.off-topic : C++ questions : Re: C++ questions Server Time
7 Sep 2024 13:26:02 EDT (-0400)
  Re: C++ questions  
From: Warp
Date: 26 Sep 2008 14:05:42
Message: <48dd2476@news.povray.org>
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Unless I'm completely mistaken, this is not something you can achieve
> > in Java. (In Java you have to close files explicitly and catch all
> > possible exceptions which might otherwise bypass that closing.)

> The destructor will close the file when the GC collects the object, but 
> that might be several seconds later.

  I don't know how it is today, but at least in the past the amount of
file handles one single program could keep open at the same time was
ridiculously limited (IIRC to a few dozens or so). If the program tried
to open more than that, it would fail.

  If a program is constantly opening files, doing something to them, and
then closing them, a file handle leak (which would happen if it fails to
close them for some reason, eg. because of a bug or a suprising exception)
can cause the program to malfunction. And this might not be caught on
testing, if the testing fails to stress the program in the same way as
it happens in actual usage...

  OTOH, I could imagine that if Java detects that a file cannot be opened
because of too many file handles being open, it could automatically try
to run the GC and then try again.

  OTOH, file handles are just *one* possible resource which can leak.
Java can't be prepared for all of them.

> And it might not run if you exit 
> the program before the GC runs, but that's true of C++ also.

  It's true of C++ only if your stream has been allocated dynamically
(directly or indirectly). If it's stack-allocated then there's no way
its destructor won't be called.

  (Ok, there is a way: If you call abort() the program is immediately
terminated without any stack unwinding, in which case no destructors
are called at all. However, abort() is such a harsh way of terminating
the program that it shouldn't happen in normal code.
  Incidentally a failed assert() calls abort(), which is the reason why
assert() should only be used to catch programming errors, not to exit
the program normally.)

-- 
                                                          - Warp


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.