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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-05-05 09:39:15

"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. An opaque external representation (or 
serialization algorithm) always leads to problems in the long run.

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

[...]

> 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.

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