From: Russell Hind (rh_gmane_at_[hidden])
Date: 2004-11-18 07:47:28
Peter Dimov wrote:
>> So maybe we can consider a practical compromise.
>> a) Grant me access to the internals of shared_ptr for now
> a) You aren't going to get access to the internals of std::tr1::shared_ptr.
> b) Your implementation doesn't work when a weak_ptr is read before the
> corresponding shared_ptr.
But in this case, the weak_ptr was also written before the shared_ptr so
when the weak_ptr was written, if it had a valid point, it should have
written the shared_ptr's object out to the archive.
What is then needed is a way to store the re-constructed weak_ptr on
reading so that it isn't automatically destroyed before a valid
shared_ptr of the same object is read back in.
> c) I "reserve the right to" change the implementation of
> boost::shared_ptr. IIUC with this implementation this will break every
> data file that contains a boost::shared_ptr. Correct?
Thats fair enough but as Neil pointed out, serialization is now an
accepted part of boost and both shared_ptr and serialization are
important part of our applications, so shouldn't we make every effort to
make the two play nicely together?
If we can't do this for std::tr1::shared_ptr, we could still do this for
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk