"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.
Honestly, I don't need to serialize std::tr1::shared_ptr - why would any of us ever use it as long as we have boost::shared_ptr which (with serialization is a superset of std::tr1::shared_ptr.)
b) Your implementation doesn't work when a weak_ptr is read before the corresponding shared_ptr.
It would seem to me that serialization a weak pointer before serializing its corresponding shared pointer would be a user error. Easily detectable at load time - (alas, perhaps too late). In general this couldn't be detected a save time. The problem is that the one might not be serializing *all* the shared pointers to a particular object. This shouldn't prevent the de-serialization from restoring a consistent subset of to original set of shared_ptrs. This is not an implementation issue. Its what has to happen to maintain consistency accross persistence/marshalling. I would expect a simple and correct serialization of weak_ptr to look something like: template<class Archive, class T> void save(Archive &ar, const weak_ptr<T> &wp){ shared_ptr<T> sp = wp; ar << sp; } template<class Archive, class T> void load(Archive &ar, weak_ptr<T> &wp){ shared_ptr<T> sp; ar >> sp; wp = sp; // note exception on exit if weak pointer loaded before corresponding shared pointer }
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?
Currently. shared_ptr<T> has a default class version of 0. This version number is in the archive and is available when the archive is loaded. Should the implemenation change in such a way that a different de-serializaton algorithm is required, the de-serialization method can be conditioned on the version number. This is described in the serialization documentation. It is possible that the change in implementation would be so drastic that this mechanism couldn't deal with it. In any case, would not such a change be subject to a mini-review? Robert Ramey