Good Design for C++ Serialization -

i^m currenty searching oo design serialize c++/qt application.
imagine classes of application organized based on tree structure, implemented composite-pattern, in following picture.

the 2 possible principles thought of:

1.)
put save()/load() function in every class has serializable. if have seen many times, implemented boost. somewhere in class find this:

friend class boost::serialization::access; template<class archive> void serialize(archive & ar, const unsigned int version) {     ar & m_meber1; } 

you seperate save() , load(). disadvantage of approach :
if wannt change serialization 2 months later (to xml, html or curious, boost not supports) have adopt thousands of classes. in opinion not oo-design.
, if wannt support different serializations (xml, binary, ascii, whatever....) @ same time 80% of cpp exists serialization functions.

2.)
know boost provides non intrusive version of serialization

"http://www.boost.org/doc/libs/1_49_0/libs/serialization/doc/tutorial.html"

so way implement iterator iterates on composite tree structure , serializes every object (and 1 iterator deserialization)
(i think xmlserializer-class of .net-framework does, i^m not realy familiar .net)
sounds better because seperate save() , load() , 1 spot change if serialization changes.
sounds better, but:
- have provide setter() , getter() every parameter wannt serialize. (so, there no private data anymore. (is good/bad?))
- have long inheritance hirarchy (more 5 classes) hanging on composite tree.
how call setter()/getter() of derived classes? when can call interface function of base composite-component.

another way serialize objects data seperate abstract format. possible following serializations (xml, text, whatever possible) data. 1 idea serialize qdomnode. think abstraction cost performance.

so question is:
know oo-design serialization?
maybe other programming languages java, python, c#, whatever....

thank you.

beware of serialization.

serialization taking snapshot of in-memory representation , restoring later on.

this great, except starts fraying @ seams when think loading stored snapshot newer version of software (backward compatibility) or (god forbid) stored snapshot older version of software (forward compatibility).

many structures can deal backward compatibility, forward compatibility requires newer format very close previous iteration: basically, add/remove fields keeps same overall structure.

the problem serialization, performance reasons, tends tie on-disk structure in-memory representation; changing in-memory representation requires either deprecation of old archives (and/or migration utility).

on other hand, messaging systems (and google protobuf is) decoupling exchanged messages structures in-memory representation application remains flexible.

therefore, first need choose whether implement serialization or messaging.

---

now right can either write save/load code within class or outside it. once again trade-off:

• in-class code has immediate access all-members, more efficient , straightforward, less flexible, goes hand in hand serialization
• out-of-class code requires indirect access (getters, visitors hierarchy), less efficient, more flexible, goes hand in hand messaging

note there no drawback hidden state. class has no (truly) hidden state:

• caches (mutable values) that, can lost without worry
• hidden types (think file* or other handle) recoverable through other ways (serializing name of file example)
• ...

---

personally use mix of both.

• caches written current version of program , use fast (de)serialization in v1. new code written work both v1 , v2, , writes in v1 default until previous version disappears; switches writing v2 (assuming it's easy). occasionally, massive refactoring make backward compatibility painful, drop on floor @ point (and increment major digit).
• on other hand, exchanges other applications/services , more durable storage (blobs in database or in files) use messaging because don't want tie myself down particular code structure next 10 years.

note: working on server applications, advices reflect particulars of such environment. imagine client-side apps have support old versions forever...