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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-19 08:46:26

Robert Ramey wrote:
> "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.)

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.

>> 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].

>> 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.