|
Boost Users : |
From: Robert Ramey (ramey_at_[hidden])
Date: 2005-09-06 15:30:54
signature
"Martin Proulx" <mproulx_at_[hidden]> wrote in message news:431DE771.6080307_at_okiok.com...
Hello,
While using the latest release of boost, I've encountered a few questions concerning the usage of the serialization library with objects without default constructors.
Here they are:
1-) How can we construct an instance of a serialized object that doesn't have a default constructor?
The only option I've figured out is to normally construct an object with bogus values, then unserialize the real values while reading from the archive. Example:
X(0) val; // 0 being some bogus value.
inputStream >> val; // Overwrites all values within val;
Is this the correct way to do things?
No.. But I think what you want can be found in the manual in section: If you specialize save/load construct data you will get what you want. Use construct in place inside of load construct data.
Reference/Serializable/Concept/Pointers/Non-Default Constructors.
2-) How should we split the serialization between the class' serialize member versus load/save_construct_data?
My observations show that when un/serializing objects directly like shown above, load/save_construct_data aren't needed, so the serialize member has to handle everything. When serializing a vector<X>, load/save_construct_data does get called, so we have to un/serialize some members in those functions as well. At first glance, it seems some members will have to be un/serialized for the second time within load/save_construct_data.
Is that correct? For a class to be correctly un/serializable for all cases, load/save_construct_data must un/serialize members that are already taken care of in the serialize member?
Nope.
If his isn't simple, then there is something wrong. Check the code in test_non_default_ctor . If it still doesn't give you what you need, ask again.
RObert Ramey
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net