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::shared_ptr. Cheers Russell