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
>> > 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
>> > 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
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk