"Peter Dimov" <[EMAIL PROTECTED]> writes: > From: "David Abrahams" <[EMAIL PROTECTED]> >> "Peter Dimov" <[EMAIL PROTECTED]> 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 [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