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

25 Jun 2005

      ----- Mensaje original -----
De: David Abrahams <dave@boost-consulting.com>
Fecha: Sábado, Junio 25, 2005 1:39 am
Asunto: Re: [boost] [serialization] a proposal for an	alternative
	to thenewconst-saving rule
...
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> writes:
...
De: David Abrahams <dave@boost-consulting.com>
...
...
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.
I'm not sure it is.  There's an imposition on users: all the types
they want to serialize have to support hashing.
No, no. Please check the piece of pseudocode on my first
message: the hash code is automatically built by
Boost.Serialization, without any intervention from the user,
and certainly without any requirement that the type be hashable
(in the sense of providing a hash_value overload or something
like this.)

Let me illustrate with an example:

struct labelled_point
{
  int x;
  int y;
  string label;

  template <class Archive>
  void serialize(Archive & ar, const unsigned int version)
  {
    ar & x;
    ar & y;
    ar & label;
  }
};

struct labelled_segment
{
  labelled_point p0,p1;

  template <class Archive>
  void serialize(Archive & ar, const unsigned int version)
  {
    ar & p0;
    ar & p1;
  }
};

So, given an object seg of type labelled_line, the framework
automatically constructs the following associated hash value:

  combine(
    combine(
      boost::hash<int>(seg.p0.x),
      boost::hash<int>(seg.p0.y),
      boost::hash<std::string>(seg.p0.label)),
    combine(
      boost::hash<int>(seg.p1.x),
      boost::hash<int>(seg.p1.y),
      boost::hash<std::string>(seg.p1.label)))

(combine(...) is shorthand for the obvious combination
formula of hash values using boost::hash_combine.)

The process recursively goes down to primitive types,
as specified in my proposed pseudocode, and only these
have to be hashable, but fortunately they are.
...
It is nice that the serialization library automatically takes care of
hashing aggregated types and leaving out the unserialized data...
uh, wait: this will never work unless you plan only to do shallow
hashing.  Otherwise you will get an exponential explosion for some
object graphs.  Is that your intention?
I'm not getting you. The hash value is calculated as part
of the saving process itself, so it has the very same complexity.
I've got the hunch you might be meaning something else,
could you please elaborate?

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