Russell Hind wrote:
Peter Dimov wrote:
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?
Yes, we should. We differ in our views as to what constitutes "every effort".
If we can't do this for std::tr1::shared_ptr, we could still do this for boost::shared_ptr.
When developing my serialization library, I have made "every effort" to support boost::shared_ptr without needing to access its implementation details, even though - being the author of shared_ptr - I can do that safely. I could have even changed shared_ptr's interface if I wanted to. But I didn't. And as a result, I can now serialize std::tr1::shared_ptr, and the serialized form does not depend on implementation details, so that I (or anyone else, for that matter, since the format is well-specified) can deserialize a boost::shared_ptr from the same archive. So "we can do this", but apparently we don't want to. If this is the case, and the current scheme is acceptable, it's easy for me to just add a friend declaration to shared_ptr and be done with it.