Boost logo

Boost :

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
> > understands
> > the system would want to do this.

> The load code DOES mirror the save code; both readins are reading
> 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
> 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
> are being too cavalier in dismissing the possibility. In fact I
> done it by accident in just that case, with a
> system not so different from the one you are proposing. A cached
> (which I wanted to save in the persistent store, because it was
> expensive to compute) was getting written dirty, then recomputed,
> saved again through another route, then the flag that it was
> was written; but the value saved was unchanged in its dirty state.
> it was a user error, but it wasn't an obvious one at the time it
> being written. It took quite some debugging effort to figure out
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at