From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2007-05-05 12:44:09
----- Mensaje original -----
De: Peter Dimov <pdimov_at_[hidden]>
Fecha: Sábado, Mayo 5, 2007 4:47 pm
Asunto: Re: [boost] Serialization support
> "JOAQUIN LOPEZ MU?Z" wrote:
> > I'm not getting you: of course if you provide serialization
> > support for a given class T, this support is usually documented
> > and thus becomes part of T's interface; what additional investment
> > are you referring to? What more do I have to document except saying
> > "T is serializable through Boost.Serialization"?
> Well... here's what I would document given a simple class:
> template<class A> void serialize( A & a, unsigned );
> Effects: a & x; a & y; where x and y are the values returned by
> x() and y(),
> "T is serializable through Boost.Serialization" doesn't tell me
> how to manipulate the result. I can neither construct a suitable
> file nor read the output.
> The external representation is observable and persistent. It can
> outlive both Boost.Serialization and Boost.MultiIndex (or their
> specific implementations) and it should be possible for an alternate
> implementation of the MultiIndex interface to read/write the same
> format. If you use serialization to send a Boost.MI object over the
> wire to another machine, it should be possible for the non-C++ program
> on the other end to reconstruct the data structure.
> Think about how people would feel when they serialize a
> std::multiindex with implementation A and can't read it with
> implementation B, as will happen if the requirement for an
> implementation is just to be able to read back what it created, not
> create a particular documented external representation.
Ok now I understand, and basically share, your concerns
about the lack of documentation on what goes into the serialization
stream. Of course I can document my part in the case of B.MI,
but for this to constitute a real cross-platform, cross-
implementation spec one would additionally need that:
1. Other serializable types (serialization primitive and otherwise)
do the same and document their way of stuffing themselves
down the wire.
2. Boost.Serialization exposes its internal mechanism for
serialization --I'm thinking here of things like versioning
and pointer tracking-- at least to the extent that they
reflect on what gets actually saved to the stream.
This initiative is interesting (and would be almost mandatory
if B.S was ever proposed to the standard) but its scope is
community-wide and beyond the realm of an isolated class'
definition IMHO. What does Robert think about this?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk