Re: [boost] Class serialization

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-09 01:34:11

Robert Ramey wrote:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:001401c4c5ec$46ea4b10$6501a8c0_at_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. :-)