Re: [boost] [serialization] a proposal for an alternative to the newconst-saving rule

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2005-06-24 15:43:47

----- Mensaje original -----
De: David Abrahams <dave_at_[hidden]>
Fecha: Viernes, Junio 24, 2005 3:49 pm
Asunto: Re: [boost] [serialization] a proposal for an alternative to
        the newconst-saving rule

> Joaquín Mª López Muñoz <joaquin_at_[hidden]> writes:
> 
> > The new rule introduced in Boost.Serialization that forbids saving
> > of non-const objects has proved a little controversial. My point of
> > view is that the rule, albeit far from perfect, provides some
> > level of safety against hard to track errors. Others' opinions 
> differ.>
> > The current rule is a rough approximation to what IMHO would
> > constitute the right enforcement: everytime a trackable object
> > is saved, check wether an object with the same address has been
> > previously saved and, if so, make sure that the object didn't 
> change.
> I don't understand what bugs this is going to catch.  Certainly in
> this case,
> 
>  for( ...
>     X x(... );
>     ar << x;
> 
> the low-level problem isn't that x is changing, but that it's a
> different object each time.

Of course.

> Two temporally different x's might well
> be identical.

Yes, but saving the same unchanged object twice,
which is perfectly legal, passes the hash test, so
the rule admits all valid cases and detects at least
some of the invalid ones --in practice, most of
them, actually.

> 
> But all of this misses the high-level problem: the author of the code
> doesn't know what he's doing.  You simply can't serialize objects from
> distinct scopes with tracking into the same archive, because there may
> be aliasing.

Totally agreed, this is what we are trying to detect
in order to protect the author of the code.

> And there's nothing we can reasonably do to detect that
> problem when the aliased objects have the same type

Nothing? I'm afraid I don't get you. A perfect
aliasing detection mechanism is probably impossible
to implement, but the hash test at least approximates it.
This is better than providing no safety mechanism,
as I understand you advocate.

Or put another way: if the hash test fires the alarm,
we are *sure* the user's code was incorrect. And
if the user's code is correct, the hash test will
pass.

If you allow me to draw an analogy, this is similar
to primality testing in maths: a 100% accurate
primality test is complexity-wise unfeasible,
but many statistical tests are fast, do not yield
false negatives and get most of true negatives right.

Am I being too cryptic? Sometimes my English skills
play tricks on me.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo