I've concluded that serializing shared pointer only depending on the std::tr1::shared_ptr interface isn't going to be possible within the current serialization library. This will have to be handled via some separate module. My aspiration is to be able to serialize boost::shared_ptr In order to do this, I would like to see access of currently private members of boost::shared_ptr changed to protected. This will allow me access through static downcasting. Feel free to include a warning/disclaimer in the source code against doing this. This should be sufficient to prevent users of shared_ptr from accidently coming to depend on the boost::shared_ptr implemenation. I will include the following in the boost serialization documentation and source code: a) a disclaimer that serialization of boost::shared_ptr does not imply serialization of std::tr1::shared_ptr is implemented. b) a warning that there is no guarentee that boost::shared_ptr will not change so much in the future as to guarentee automatic compatibility with previously written archives. "Peter Dimov" <pdimov@mmltd.net> wrote in message news:009001c4cd69$3bb90d60$6501a8c0@pdimov2...
Robert Ramey 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.
I realize that - I aspire only to serialize boost::shared_ptr
b) Your implementation doesn't work when a weak_ptr is read before the corresponding shared_ptr.
Correct, that will have to be a limitation for the time being.
c) I "reserve the right to" change the implementation of boost::shared_ptr.
ok
IIUC with this implementation this will break every data file that contains a boost::shared_ptr. Correct?
Correct - if the change is such that the current versioning mechanism can't be used to maintain compatibility with this version. From what I've seen, this would seem unlikely. Robert Ramey