Re: If GC is the solution, then what is the problem?
James Dennett wrote:
kanze wrote:
Andrei Alexandrescu (See Website For Email) wrote:
Graham Menhennitt wrote:
No, I said types of classes. Objects are not classes.
Classes are not objects (in C++). There are two categories
of classes that we're talking about. Those that have
trivial destructors and those that don't.
I think this is a good point. The fact that a class might
switch status from a GC-able class to a non-GC-able class
might cause quite a disturbance in a mixed system.
The problem is that GC-able or not is linked to what the
class does. And you can't just change what a class does (GC
or not) without re-evaluating its use. A class or a
function has a contract. If the contract says that the
class must be explicitly deleted in some specific case,
fine. If it doesn't, you can't replace it with one that
does, even today. The class user must know his end of the
contract.
Today* the implicit contract is that when you no longer need
to use an object, you ensure its destruction, and resources
used by that object will be released. Anything else requires
written documentation.
("Today" assuming no GC, that is.)
There's certainly something in that. The situation today is
that all contracts explicitly must involve ownership issues.
You have to know who is responsible for deleting an object. The
contracts of the class user implicitly suppose that this is
necessary, and take steps to ensure that it occurs at the
correct moment.
You don't just implicitly delete because you no longer need to
use an object. There are a lot more conditions which must be
considered---whether the object is dynamically allocated to
begin with; whether you are the last user, etc.
You are correct, however, that the implicit contract for a given
object is that it needs deletion. I'm not really sure what this
means---needs deletion when, for example. Could I defer it to
finalization, for example? Generally not, if it needs deletion
immediately. But then, where in the current implicit contract
does it say that I can't defer deletion to some later, more
convenient time. The issue isn't 100% black and white, even
concerning the current contracts.
Still, I would suppose that during the transitionary phase, the
only safe approach would be to suppose that delete is necessary,
until the contract was respecified. To date, most of my
experience with garbage collection is in new projects, where
this hasn't been an issue. Retrofitting it into existing
applications is another issue, which I've not addressed as yet.
In a C++ with GC, implementation details leak to the contract;
if my class changes its implementation so that it uses a
resource that requires explicit release, then my class is no
longer GC-able, and clients need to know about that. In the
world without GC, they don't need to care; they were going to
ensure timely destruction anyway, as it's standard practice.
People keep mentionning this, but I've never been able to even
imagine a realistic example. (Maybe some sort of optional disk
caching. But typically, the client must be made aware anyway,
in order to avoid excessive thrashing.)
And I'm not sure that "timely destruction" is really standard
practice; you'd have to define "timely" first. Classes that do
need relatively rapid destruction already have to specify this,
since deferring destruction (by passing the objects off to a
thread with lower priority) is already pretty much standard
practice in applications where reactivity is an issue.
It would help if GC-ability was part of the type of a class,
so that the compiler could do some checking for us if a class
changes so that it's no longer suitable for GC -- even if the
rest of its interface is unchanged.
The current proposal does contain something along these lines, I
think, although I don't think it is linked with the type system.
I agree that something is necessary to be able to specify that
certain code is incompatible with certain uses of garbage
collection, but I'm not sure that it has to be part of the type
system.
Threading and garbage collection are being handled by the same
subgroup in the committee. And since threading is even more
important, and also far more contentious, it got all of our
attention. There actually seems to be pretty much of a
consensus in the committee that "some form" of garbage
collection should be in the next version of the standard. But
as long as we haven't actually defined that "some form", I don't
think that really means much. (Nothing seems to destroy
consensus faster than actually specifying what is meant.)
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]