At 11:04 AM 1/7/2003, William E. Kempf wrote: >> 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.
Right. You need finally clauses for most resource management. A GC for C++ could just as easily never call destructors, and provide a separate mechanism for optional finalizers. > 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. That is one reasonable approach. The collector can make it easier by providing a topological sort of the soon-to-be-dead objects, so that you can safely dereference pointers in the destructors. But then you have to do something else for cycles. Like I said, the GC experts have been discussing this for years without any clear resolution. >> >> 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? It probably can be, but the literature so far indicates that it isn't. A collector that has compiler support and knows all about how the stack and heap are laid out and can take advantage of the virtual memory hardware and so on has a big advantage. It's also nice to be able to use raw pointers to collected objects. Still, a portable smart pointer GC would be nice to have, as it will take years of work to see GC added to C++, if it ever happens at all. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
