From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-21 00:34:32
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
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
I will include the following in the boost serialization documentation and
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_at_[hidden]> wrote in message
> 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
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
> IIUC with this implementation this will break every data file that
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk