> From: David Abrahams <[EMAIL PROTECTED]> > "William E. Kempf" <[EMAIL PROTECTED]> writes: > > From: "Peter Dimov" <[EMAIL PROTECTED]> > >> 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. > > > > This just pushes the issue off on the end user... who may not be any > > more capable of dealing with the problem either. If he can't do a lot > > of book keeping to handle the circular problem, then pushing it off on > > him is not much help. And if he can do the book keeping, there's > > probably a solution he can code into the destructors themselves. > > What Python does is to collect only the memory from cycles, without > calling __del__ (the equivalent of a destructor). It also provides a > similar function which gets you a list of the objects that are in > cycles.
A solution like this for C++ could easily result in memory leaks. If the object in question did it's own internal memory allocations which would normally be cleaned up in the destructor, you've got a leak when the "collector" releases the object's memory with out calling its destructor. William E. Kempf [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
