Robert Ramey wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:001401c4c5ec$46ea4b10$6501a8c0@pdimov2...
Specifically, the current scheme for serializing a boost::shared_ptr is suboptimal, because it can't be used with another implementation of std::tr1::shared_ptr.
In general, serialization for any class is specific to that class implementation.
No, this is not true in general. It depends on whether (a) you want the external representation of the class to represent its logical state, and (b) whether it is possible for the user to obtain this logical state and reconstruct a new object based on it. To take a classic example, if you have a class point2 that exposes x() and y(), it can be serialized in a (x y) format, regardless of its physical representation that can be (r phi), for instance. I'd say that many of the general library classes fall in this category.
I don't think makes sense to require that a serializtion implementation be independent of the particular class implementtion.
It doesn't make sense if you have control over the class in question. However would you consider a scenario where a std::vector<int> written out by a program compiled with STL A cannot be read by a program compiled with STL B? A recompiled version of the same program with the newer version of the compiler? Now replace std::vector<int> with std::tr1::shared_ptr<X>. BTW there's one more problem with trying to serialize shared_ptr using the physical state; weak_ptr deserialization cannot work reliably. That's because it is possible to write the weak_ptr before the corresponding shared_ptr. Then no matter what you do on reading, either the object will be immediately destroyed after being created (there are no shared_ptrs to it, only a weak_ptr), or it will leak. Correct deserialization of shared_ptr/weak_ptr requires keeping a container of shared_ptr<void> that holds the objects alive during the deserialization process. The problem I've not been able to solve so far is where to keep it without making shared_ptr special WRT the archives. :-)