
Robert Ramey wrote:
Well, restoring objects using some sort of factory would give us a proper mechanism to restore objects with non default constructors or const members that haven't been serialized through pointers. That would be one way to overcome the assignment like limitation of restoring through operator>>. I believe the idea of a factory also holds well to restore objects serialized through pointers where the objects have to actually be reconstructed.
what I really mean is what is the matter with
class A { const X m_x ... template<class Archive> void serialize(Archive & ar, const unsigned int version){ ar >> const_cast<X>(m_x); } };
Doesn't this give the same result in a simpler more transparent way?
It's true that this is a simple way to do the following: A a(/* With a possible bogus and temporary value for m_x); ia >> a; Now if this is simpler and more transparent than doing something like this: A a(restore_object<A>(ia)); ...I'll leave for C++ language lawyers and you to decide. They just don't mean the same thing, even if the end result might be the same. You can achieve the same results with copy constructors or assignment operators, but they're not the same. As a user, what really isn't simple or transparent is that with the above operator>> solution, for objects without a default constructor, I have to define serialize differently depending if load/save_construct data is called or not. Should I take care of the members needed to reconstruct an instance or not in serialize? I have to know enough about the library to know that serializing an "A*" or a "vector<A>" does call them, but that serializing a "const A&" doesn't. Now what about an array of A??? I believe making an object serializable would just be simpler if the following would be true: -) save_construct_data and load_construct_data are always used. -) We have some function that constructs and returns an object instance using load_construct_data. This removes the possibility of doubly serialized members, the need to const_cast, temporary objects created with bogus parameters, and the ambiguity of what members serialize should take care of. Martin