|
Boost : |
From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-07 13:04:16
> From: Greg Colvin <Gregory.Colvin_at_[hidden]>
> At 09:23 AM 1/7/2003, Peter Dimov wrote:
> >From: "William E. Kempf" <wekempf_at_[hidden]>
> >>
> >> I think that extending it to free memory in cycles would be a great idea.
> >Of course, this opens a large can of worms about how to handle destruction
> >of objects which refer to each other...<
> >
> >One possible approach is to return a list of references to the "offending"
> >shared_ptr instances to the user, who can then reset() them as appropriate.
> >Actually it's not as simple as that since a reset() can invalidate some of
> >the returned references; the shared_ptr instances would first need to be
> >copied to a temporary container, the originals reset(), and the temporary
> >container destroyed, but the general idea is the same.
>
> Finalization semantics is of course a very big can of worms
> that has kept a lot of GC experts arguing for years. But I
> take the success of Java as evidence that getting it right
> might not be all that important.
The "Java solution" is to not have a solution. Finalizers need never be called in Java. I'd prefer to always call the destructors, with the knowledge that dereferencing a GC pointer that's participating in a cycle during the destructor results in undefined behavior. I can usually avoid doing this.
> >> I think that full GC is one of the major things missing from the C++
> >language, and the appeal of a smart pointer approach, where I pay for GC
> >only when I want/need it, is a great idea.<
>
> A smart pointer approach is the only way I know to write a
> portable collector, but it is not really the best way to
> write a high-performance collector. My preference is to
> have a special new(gc) allocator for collectable objects,
> and compiler support for a collector that can scan all
> objects for pointers to collectable objects. If new(gc)
> is never called there need be no overhead.
Creating an efficient GC system is tricky, yes, but I don't see why a smart pointer approach can't be just as efficient as a compiler solution?
William E. Kempf
wekempf_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk