Re: [boost] Serialization support

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-05-05 10:46:19

"JOAQUIN LOPEZ MU?Z" wrote:

> De: Peter Dimov <pdimov_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"?

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(), 
respectively.

"T is serializable through Boost.Serialization" doesn't tell me how to 
manipulate the result. I can neither construct a suitable input file nor 
read the output.

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

Those Microsoft is having with its file formats. ;-)

> In which sense is treating the
> external representation as an opaque entity different from
> treating the *internal* representation as an implementation
> detail?

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.