Re: [boost] Serialization support, Was: [BoostCon07][testing] Session reminder.

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2007-05-05 10:12:51

----- Mensaje original -----
De: Peter Dimov <pdimov_at_[hidden]>
Fecha: Sábado, Mayo 5, 2007 3:40 pm
Asunto: Re: [boost] Serialization support,Was: [BoostCon07][testing] 
Session reminder.
Para: boost_at_[hidden]

> "JOAQUIN LOPEZ MU?Z" wrote:
> 
> [...]
> 
> >   a) data intrusive: the stuff serialized reflects the internal
> >   structure of the class. The set<int> example proposed by Peter
> >   above illustrates a case of (unwise) data intrusive 
serialization.
> >   b) interface intrusive: the serialization algorithms cannot be
> >   implemented by using the class public interface alone. For
> >   instance, up to Boost 1.33 (if my memory serves me well),
> >   serialization of shared_ptrs was provided in an interface
> >   intrusive way because no non-intrusive approach was found --this
> >   has fortunately been corrected now.
> 
> There is no such thing as "interface intrusive" serialization if 
> you consider the serialization support a part of the documented 
> interface of the class. I admit that this requires additional
> investment and is rarely done, but it's the only way to do it
> right. 

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"?

> An opaque external representation (or serialization algorithm)
> always leads to problems in the long run.

What kind of problems? In which sense is treating the
external representation as an opaque entity different from
treating the *internal* representation as an implementation
detail?

> (shared_ptr's 1.32 serialization was "data intrusive".)

I stand corrected.

> [...]
> 
> > So, I had no other choice but to implement serialization
> > support for Boost.MultiIndex in an interface intrusive way.
> > The morale of the story is: for rich-state classes where the
> > exact state of an object depends heavily on its past history,
> > non-intrusive serialization can be either algorithmically
> > unfeasible (it is hard or impossible to reconstruct the
> > history from the current state) or potentially less efficient
> > than a interface intrusive approach. This does not mean that
> > the class interface or the serialization support implementation
> > are "broken".
> 
> If the ability to reconstruct a MultiIndex container in a 
> particular exact state is important, there should exist a
> documented way to do that. 
> Deserialization is not a special case.

On the contrary, I think deserialization is synonymous with
"reconstructing an object in a particular exact state". The
only specificity about this is that one choses Boost.Serialization
as the reconstructing API instead of something else. But
this is as good a choice as any other API (or better, if
Boost.Serialization gains momentum as the de facto standard
serialization interface, which would be great). So, I think
I basically agree with what you say next:

> (This doesn't mean that the deserialization support cannot be this 
> documented way, of course.) 

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