"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.
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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
