Re: Serialization (Persistence) library draft submission

From: rameysb (ramey_at_[hidden])
Date: 2002-02-28 16:15:54

> > //////////////////////////
> > > int * x = new int;
> > > *x = 5;
> > > oarchive << x;
> > > *x = 8;
> > > oarchive << x;
> > 
> > > int * y;
> > > iarchive >> y;
> > > int * z;
> > > iarchive >> z;
> > > cout << y << z;
> > 
> > This would be an error.  The load code doesn't mirror the
> > save code.  I can't prevent anyone from doing this.  And no one 
who 
> > understands
> > the system would want to do this.

> The load code DOES mirror the save code; both readins are reading 
in 
> pointers to int, both writeouts are writing pointers to int. The 
> problem is that between the two saves, something changed.

> Of course you don't WANT to do this. But it can happen by accident, 
> especially in the presence of various forms of caching in the 
objects 
> the user is serializing. I don't know if there's any easy way to 
> prevent it while still getting the behavior you want, but I think 
you 
> are being too cavalier in dismissing the possibility. In fact I 
have 
> done it by accident in just that case, with a 
serialization/persistence 
> system not so different from the one you are proposing. A cached 
value 
> (which I wanted to save in the persistent store, because it was 
> expensive to compute) was getting written dirty, then recomputed, 
then 
> saved again through another route, then the flag that it was 
correct 
> was written; but the value saved was unchanged in its dirty state. 
Yes, 
> it was a user error, but it wasn't an obvious one at the time it 
was 
> being written. It took quite some debugging effort to figure out 
why 
> the state was corrupted on restore.

> And yes, all the save functions involved were const or took const 
> references. Since a pointer to non-const can be converted to 
pointer to 
> const, this didn't save us.

> George Heintzelman
> georgeh_at_[hidden]

Honestly, I have only used this kind of code for saving and restoring
class member variables so these cases are foreign to me.  In this
context the code would look like:

class C
{
    int *x;
};

void save(oarchive &ar) const
{
    int * x = new int;  //compile time error due to const above
    *x = 5;
    ar << x;
    *x = 8;
    ar << x;
}

The concept that the saving an objects state alters that same state
seems to me something that should and can be avoided.  I don't 
know how it could be enforced though.

I am intrigued that there a applications for this that have never
occurred to me.  I have always considered just "save and restore an 
object state".   Its not clear that this characterization applies to 
you example.  Maybe why that's why I never considered it.

I believe that we have done the best we can for such situations.

Robert Ramey