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

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2007-05-06 04:28:05

Peter Dimov wrote:
> Nicola Musatti wrote:
>> Peter Dimov wrote:
>> [...]
>>> If your serialization methods
>>>
>>> - allow creation of objects whose invariants do not hold, or
>> Of course. This is analogous to writing a buggy copy constructor.
>>
>>> - expose implementation details in the external representation,
>> This is more tricky: you may want to serialize an object which is in a
>> state that in normal circumstances is not the direct outcome of
>> construction, but rather is the result of some activity. How can you
>> manage that? Either you provide a special purpose constructor or you
>> open up the object's internal state.
> 
> You store information that allows you to reconstruct the state. There is no 
> need to open the object's internal state, and it is not entirely clear what 
> you mean by that. 

I don't think we're saying very different things; in order to make use 
of the information you mention above it is likely that your class will 
need specific member functions, that are not strictly required to 
fulfill the class's primary responsibility. I believe this is what 
Joaquin refers to as "interface intrusive".

Elsewhere you argue for an external representation that captures a 
class's conceptual behaviour without exposing the details of a specific 
implementation. While I'd agree that this is a sensible objective for a 
general purpose library, and even more for a standardized serialization 
approach, in application development it might be overkill, and sometimes 
just dumping a subset of a class's data members may prove more effective.

Cheers,
Nicola Musatti