Re: Serialization (Persistence) library draft submission

From: rameysb (ramey_at_[hidden])
Date: 2002-02-27 18:14:46

--- In boost_at_y..., "George A. Heintzelman" <georgeh_at_a...> wrote:
> Hmm. Yes, but. I am somewhat concerned because pool implementations 
are 
> likely to produce objects which have the same address as previously 
> existing ones of the same type, and I worry that some naivete' here 
may 
> lead someone to problems. I don't have a concrete example though, 
> except of course for deliberate sabotage.

Previously serialized addresses of the same type are fine as long as 
they
are serialized the same way.  The problem occurs only when it is
serialized different ways.  So it turns out that things like maps
and lists of duplicated pointers, etc work fine.   I believe the
situations where this would be a non-trivial problem - if they exist
would have to be contrived.

> More worrisome to me is trying to use a serialization library -- 
which 
> I see as a fairly fundamental piece -- to implement more 
complicated 
> functionality. For example, it seems natural to want to use a 
> serialization library under some persistence or object database 
> library. In such cases, saving and restoring pointers is a much 
more 
> complex issue, and I worry that your implementation could 
interfere. So 
> even if you have a default mechanism in place, perhaps a user ought 
to 
> be able to replace the mechanism?

Its hard for me to comment on this without a more concrete example

>> This presumes that the state of the objects doesn't change when an 
>> archive is being written or read. This implementation of the 
library 
>> makes this assumption. I havn't considered what would happen if 
this 
>> assumption didn't hold. In an attempt to enforce this assumption, 
>> all the class member save functions are marked const. This should 
>> prevent the data from being changed while being serialized.

> The assumption is not an unreasonable one, though it needs to be 
> explicit in documentation. But I fear the constness of class member 
> save functions will help you little, if at all:

> class Y;
> class X {
> scoped_ptr<Y> p;

I believe that this not a serious problem.  When class members are
serialized they are also serialize through const functions.  So
the whole call stack is instantiated with constant functions. This
occurs only when serializing through pointers.  So I believe that
is why the problem never comes up.

> I'm not sure it is that easy to avoid. It would probably be fairly 
> common to give out pointers/references to elements of a map which 
is a 
> data member, for example. I know that I do this frequently. If one 
were 
> writing from scratch, it might be possible to avoid, but to 
retrofit a 
> workaround onto an existing class seems like trouble.

I don't believe this is any problem - I do it all the time see above.

Robert Ramey