> From: "Peter Dimov" <[EMAIL PROTECTED]> > From: "William E. Kempf" <[EMAIL PROTECTED]> > > > From: "Peter Dimov" <[EMAIL PROTECTED]> > > > 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. > > > > 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.< > > No, the user would not be expected to do any bookkeeping. He would only need > to call find_unreachable_objects() that would return a list of the > unreachable objects, and then, optionally, call break_cycles() with that > list as an argument. Or something like that. :-)
And how would break_cycles() accomplish its task with out book keeping? William E. Kempf [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
