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