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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk