[boost] Re: Re: Re: shared_ptr and serialization

19 Nov 2004

      "Peter Dimov" <pdimov@mmltd.net> wrote in message
news:008d01c4ce3e$2b37d4f0$0600a8c0@pdimov...
...
Robert Ramey wrote:
...
"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.)
I see your point of view, but I'm not sure that you see mine.
At issue is which is more fundamental, serialization or shared_ptr. Your
desire to treat shared_ptr as yet another user-defined type is
understandable, but if you substitute std::map for shared_ptr, you'll see
that this stance is not sustainable in general. Even if we had a
boost::map.
There will always exist types that must be serialized non-intrusively.
I do see you're point.  I just don't see a way to address it.  So far
shared_ptr is the only standard libary component which can't be serialized
from its public interface.  I came upon this is issue after doing pretty
much everything else and need and non-trivial use case.  I concede its hard
to create a public interface for shared_ptr to support serializaion (It's
probably not even possible).  I know its hard  (if its possible at all) to
create a public interface in the serialization library to permit
serialization something like a shared_ptr  If it were possible, it would end
up adding lots of complexity to the serialization library to handle one case
(so far).
...
...
...
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.
No, it's not a user error at all, it's a perfectly reasonable scenario. I
have, at the moment, three such structures. Here's an example:
vector< shared_ptr<X> > v;
where the relevant part of X is:
struct X
    {
        weak_ptr<X> target_;
    };
v[0]'s target_ can easily be v[1].
the de-serialization of a vector is somethng like:

template<class Archive, class T>
void load(Archive ar, vector<T> & v){
    unsigned int count;
    ar >> count;
    v.clear();
    while(--count){
        T t;
        ar >> t;
        v.push_back(t)
   }
}
...
From my reading of the weak_ptr document, a weak_ptr cannot point to
anything if there is no existent correspnding shared pointer.  So the above
would necessarily fail unless a shared_ptr was previously serialized in the
same archive - which is not guarenteed.  In order to use such a data
structure, the default implementation of the serialization of vector would
have to be overriden.
It is possible to concieve of data structures that are not serializable by
this library.  I havn't had such cases reported to me so I presume they are
infrequently, if ever, encountered by users of the boost serialization
library.

So perhaps rather than the term "user error", it might be more palatable to
describe it as "unsupported by the current default serialization library
implementation".
...
...
...
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?
A mini review for each change of undocumented implementation details? Sign
me up.
I understand your objection to boost::serialization depending upon the
implementation details of boost::shared_ptr.   I just don't see any way to
address this other than making big changes to either the serialization
libary or shared_ptr.  Even then, its not obvious to me that its even
possible.

So the question is what do provide for users now?

Robert Ramey