Re: Garbage Collection - The Trash Begins To Pile Up
* Mirek Fidler:
Dave Harris wrote:
RAII and reference-counting are not 100% solutions.
Consider the classic example of an RAII File object closing the file
handle in its destructor. Closing the file may cause write-buffers to be
flushed to disk, and that may fail (eg due to hardware error or the disk
being full). How do you handle the error?
Yep, good point. If you want to detect error writing to disc, you have
to flush and check before destructing. How will GC help you here?
I don't know what Dave Harris really meant to say (I've read his
posting), but the example is IMHO an important one in the context of
lifetime management, though as I see it unrelated to reference
counting/RAII versus general GC.
There are three problems.
The first problem is simply that the usual file object, such as a
std::ifstream, lumps together at least two interfaces that really should
be separate: one interface or set of interfaces for gaining access to
and perhaps also information about the file, and one interface for file
content operations. When a content operation fails, the content
interface should in general be made unavailable until valid access has
been re-established (if ever), while the access interface(s) needs to
still be available in order to fix things or close the file. SomeBody
(TM) please look up the pattern names for this, an object that changes
its available interfaces -- essentially it's "type" -- dynamically.
In C++ doing this safely generally necessitates using a special kind of
smart-pointer as the client code's interface, lest one ends up with
error state checking peppered all over the code. But smart pointers are
generally associated with dynamic memory allocation, and so for reasons
of PREMOPT and perhaps a sense of simplicity the usual file object
instead just enters a "swallow errors" zombie state where content
interface operations are ignored. And when the file object class is
designed this way, the simple state change becomes a problem.
To sum up, for this first problem the solution is just better design (or
just design) and refraining from PREMOPT. RAII can simplify but isn't
essential. General GC doesn't really help, but isn't a problem, either.
The second problem is that of overriding parts of a base class'
destruction functionality in a derived class; e.g., IIRC this was/is a
problem in the MFC C++ framework. Say that ~File is complex, and
somewhere in all that code calls close(). In the derived class
SpecialFile one wants to override only close(), but while well-known
solutions exist for the corresponding construction problem (DBDI, see
FAQ item 23.6), AFAIK solutions for destruction, DBDD?, are not
well-known. However, the DBDI solution /concepts/ are applicable, which
again means just better design (or just design) and refraining from
PREMOPT, and is independent of reference counting versus general GC.
The third problem is that of handling destruction failure so that
destruction during stack unwinding is in some sense well-behaved.
AFAIK this third problem has (as yet) no general solution, regardless of
reference counting or general GC.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]