Boost logo

Boost :

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2005-06-24 03:27:50


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.

The hardest part is checking for equality. My proposal is
to follow a hash-based approach, which is effective both in
terms of complexity and space (one word per tracked object.),
and does not impose any special requirement on the serialized
objects (for instance, an approach based on operator== would
require that objects be equalitycomparable).

How does one compute a hash value for an object being saved?
It is easy to do recursively as follows (pseudocode):

unsigned int* hash_addr=0; // a member of the current archive

internal_save(object obj)
  if(hash_addr!=0 || obj is trackable)
    // a hash computation is in course or we need to initiate one

    unsigned int* old_hash_addr=hash_addr;
    unsigned int h=0;


      // add h to the hash being computed

user_defined_save(primitive_type x) // provided by Boost.Serialization

  // rest of serialization stuff, as always

This implementation does not impose any additional requirement
on the objects being serialized and is totally transparent to the
user (she doesn't have to do any hash-related work herself.)
With the computed hash values, Boost.Serialization can emmit
run-time errors if a trackable object is serialized twice and
changed in between (currently, the errors are compile-time.)

What do you think?

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

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