[boost] Re: Re: shared_ptr and serialization

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-19 01:56:24

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:009001c4cd69$3bb90d60$6501a8c0_at_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