[Issue 1250] std.stream.BufferedFile should have a destructor with close()

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon May 28 11:48:34 PDT 2007


http://d.puremagic.com/issues/show_bug.cgi?id=1250





------- Comment #2 from wbaxter at gmail.com  2007-05-28 13:48 -------
(In reply to comment #1)
> You can't do that; it causes undefined behavior if BufferedFile is collected by
> the GC. BufferedFile internally uses a File, and GC-collected objects can't
> safely reference other GC-able objects in their destructors since they may have
> been collected earlier and accessing deleted objects is Bad(TM).
> File can call close() in the destructor because it doesn't need to access
> GC-able objects to close(), it just performs the needed OS calls directly.

Ouch.  That kinda defeats one of the major purposes of having 'scope' in the
first place.  Sounds like D needs that "scope destruction" flag passed to the
destructor as has been suggested before, so that people have a way to make
their classes work optimally with scope.

> The only way to safely put a close() in the destructor of BufferedFile (or
> BufferedStream, its superclass) would be to make it a "scope" class to require
> deterministic destruction, but that would disallow a lot of use cases.

...which is basically always the case.  No one wants to slap a 'scope' on a
class because it just limits the possibilities.  I guess you could derive a
ScopeBufferedFile from BufferedFile and make that a scope class.

scope ScopeBufferedFile : BufferedFile {
   ~this() { m_file.close(); }
}

Seems kind of inelegant, though.


-- 



More information about the Digitalmars-d-bugs mailing list