Re: If GC is the solution, then what is the problem?
peter koch larsen wrote:
kanze wrote:
marius lazer wrote:
kanze wrote:
"What" is we didn't need GC to write a delete-free
very complex application. I don't oppose GC, just
don't see the need for it.
I'm not sure I understand. There are no deletes in your
code, or just that you've spent a lot of time and effort
ensuring that they are all in one or two isolated
classes, smart pointers, or whatever.
They are all done by smart pointers.
Which means that you have to deal with several different
types of pointers. Additional cruft that I can do without.
[snip]
Using smart pointers means additional coding.
Except that one single type of smart pointer doesn't cut
it. You have to deal with cycles, etc. And there are
places where smart pointers aren't appropriate.
True, we picked the right smart pointers at design time.
But you still have to use them. Different pointers in
different places. (There are times when this is justified
with garbage collection as well, but they are considerably
less frequent.)
[snip]
Actually, I suppose, you decide on a few widely used
policies, and typedef them. In which case, it comes out to
pretty much the same thing as using the boost smart
pointers. Which, as anyone who's tried it can tell you, is
a lot of extra work.
[snip]
Out of curiosity, I would like to know in how many places
where you today use a plain pointer with garbage collection
you couldn't use a boost::shared_ptr and get the same effect
(except for performance considerations).
The obvious question here is: what is the advantage of using
boost::shared_ptr for garbage collection, when real garbage
collection is more efficient. And doesn't have the problems of
cycles. And eliminates the need for non-trivial destructors,
which results in more deterministic behavior. (More accurately,
of course, it moves the indeterminism elsewhere:-). But since
so many opponents of garbage collection seem to like to play
word games...)
Also, I'd be interested in why you can't use the shared_ptr -
e.g. if it is because of cycles or you do have other concerns.
Cycles are an obvious concern---bi-directional navigation is a
fact of life in entity objects. Of course, entity objects have
an explicit lifetime, so you don't need shared_ptr to manage
them. But then we're back to managing different types of
pointers. (And IMHO, to explicitly end the life of an object,
something like "delete this" is a lot clearer than assigning
null to some smart pointer.) And of course, cycles also show
up as soon as you have lists or graphs of any sort.
There are also cases where some of the objects are static or
local, and not allocated dynamically. There are ways of
handling this with boost::shared_ptr, so the type doesn't
change. But the initialization of the first pointer requires
special handling.
Another concern with boost::shared_ptr is that once an object is
controlled by a shared_ptr, you cannot use other pointers with
it. I do a lot of multi-threaded work, and it is a basic rule
that when passing objects between threads, auto_ptr is used;
once you've handed the object off, accessing it is a major
programming error. (I even use auto_ptr with garbage collection
here. Because I'm not really using it for memory management,
but for its more general ownership semantics.) Once a
shared_ptr has control of an object, however, it can't
relenquish it, so you can't make an auto_ptr out of it.
There are solutions for all of these problems, of course.
They're just more work. I find that on a typical application
where I have access to the boost smart pointers, I still end up
with more raw pointers than all of my smart pointers combined.
--
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! ]