----- Mensaje original ----- De: Peter Dimov <pdimov@mmltd.net> Fecha: Sábado, Mayo 5, 2007 3:40 pm Asunto: Re: [boost] Serialization support,Was: [BoostCon07][testing] Session reminder. Para: boost@lists.boost.org
"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