[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