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. >> 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. >Making a real "zero overhead" collector is a bit harder, and I'm not sure I >have the time to do it. > >The main requirement is the ability to discover all active counted_base >objects; currently I maintain a global std::map of their addresses, and >that's probably not acceptable for production code. A dedicated allocator >that provides the ability to enumerate allocations may help here. > >An additional requirement is to be able to discover shared_ptr subobjects >and to distinguish a shared_ptr from a weak_ptr; I've used a "magic >constant" but this increases sizeof(shared/weak_ptr) from 8 to 12 on a >typical implementation. It is possible to "mangle" the object pointer (by >XOR-ing it, for example) in weak_ptr and replace the magic constant test >with a valid pointer test, but I'm not sure whether this is a good idea. :-) My old cyclic_ptr code is still somewhere on the Boost pages, and might offer a better solution to these problems. But I just haven't had time or motivation to integrate it with shared_ptr. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
