Re: [boost] Shared_ptr "mini garbage collector"

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-07 16:58:37

"Peter Dimov" <pdimov_at_[hidden]> writes:

> From: "David Abrahams" <dave_at_[hidden]>
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>> > It's true that, in general, there is no safe way to break the cycle; x1
> may
>> > keep a raw pointer to x2, or it might be a X invariant that X::p is
>> > non-empty, causing ~X to fail. This is why the final decision to break
> the
>> > cycles should be left to the user, and the collector should not
>> > automatically reclaim memory. Still, most reasonable classes would be
>> > collect-friendly.
>>
>> Isn't the biggest problem one of system design?  How does the user
>> write the cycle-breaking code which does different things based on the
>> dynamic type of the objects being referenced?
>
> The user doesn't need to write any cycle-breaking code. All that is
> needed is to reset() the shared_ptr instances that keep the cycle
> alive. I.e. the requirement is that the object's invariants must not
> be broken if a shared_ptr member is suddenly reset.
>
> It's not necessary to know the T in shared_ptr<T> in order to reset it if
> shared_ptrs are layout-compatible (true on most implementations.)

Yes, but IIUC the reason the library's not doing it is because you
might get the order wrong, which could cause a problem like a dangling
pointer needed for some destructor.

How will the user decide the order if not by examining T?

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