This is the mail archive of the
mailing list for the GCC project.
RE: Of Bounties and Mercenaries
- From: "Stephan T. Lavavej" <stl at caltech dot edu>
- To: "GCC" <gcc at gcc dot gnu dot org>
- Date: Mon, 5 Apr 2004 22:23:48 -0700
- Subject: RE: Of Bounties and Mercenaries
- Reply-to: <stl at caltech dot edu>
> As much as I like C++, I don't see how switching to it would
> do away with our need for garbage collection.
It's pretty simple, really. Garbage collection is a morally bankrupt idea.
Now, it's probably a step up from manual memory management, which is what C
will otherwise force you to do, but that doesn't say much.
In C++, you can use Resource Acquisition Is Initialization (RAII). You
delegate resource management to objects; when the objects are constructed
and initialized, they acquire their resources, and when the objects are
destroyed, they release their resources.
Now, if you work with local objects all of the time, they die at the ends of
their blocks and all is well. If you need to manage collections of things,
use STL containers, which will gather and release resources as necessary.
The interesting part is what to do with resources that do not have obvious
copy semantics (files, sockets, etc.). Have resource manager classes that
derive from boost::noncopyable, and then maintain shared_ptr's to them.
When you need a file, or whatever, construct it (acquiring the resource)
with /new/, and immediately hand it off to a shared_ptr. You can then copy
that shared_ptr at whim, put it in containers, pass it to functions, and it
will always refer to the same file. When all the shared_ptr's die, then the
file is released.
This means: do not use /new/ unless you are immediately handing something
noncopyable off to a shared_ptr, and do not use /delete/.
The one exception: When you need something exotic, write your own
resource-managing class. It can use new and delete and good old fashioned
manual memory management all it likes, as long as it stays confined to that
Using this philosophy, the resources manage themselves, rather than you
having to do it (traditional C) or having a garbage collector do it (with
the associated locality problems).
> And then, in order to enjoy the benefits of C++, we'd have to
> pretty much rewrite gcc from scratch
That's funny; I always considered Fred Brooks a demigod.
Joel Spolsky misquoted Brooks, by the way. He actually said (emphasis his):
"/plan to throw one away; you will, anyhow/"
Stephan T. Lavavej