From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-19 08:46:26
Robert Ramey wrote:
> "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
> 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:
v's target_ can easily be v.
>> 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?
> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk