From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-09 01:34:11
Robert Ramey wrote:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
>> 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
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
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. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk