> From: Greg Colvin <[EMAIL PROTECTED]> > At 09:23 AM 1/7/2003, Peter Dimov wrote: > >From: "William E. Kempf" <[EMAIL PROTECTED]> > >> > >> 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 [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
