Re: [boost] Shared_ptr "mini garbage collector"

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-07 11:54:27

"William E. Kempf" <wekempf_at_[hidden]> writes:

> From: "Peter Dimov" <pdimov_at_[hidden]> 
>> 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.

I know that re-using memory which contains an object without a trivial
destructor is technically undefined behavior, but it's hard to imagine
an implementation where it would be a problem.  This would still
"simulate infinite memory", though if you were comparing memory
addresses you might notice some repetition ;-).

I don't know if an approach like this is possible for shared_ptr.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution