|
Boost : |
From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-07 12:22:16
> From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "William E. Kempf" <wekempf_at_[hidden]>
> > > From: "Peter Dimov" <pdimov_at_[hidden]>
> > > From: "William E. Kempf" <wekempf_at_[hidden]>
> > > > 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
wekempf_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk