JOAQUIN LOPEZ MU?Z wrote:
Thanks for pointing me to test_non_default_ctor.cpp. I think this example nicely illustrates the purposes which (load|save)_construct_data is meant to serve, and that you've summarized in your comments above:
* handle types without a default ctor. * serialize data used at construction time which are *not* serialized by T::serialize.
and this is all good, but if I'm understanding you right then you're stating (in agreement with my analysis) that (load|save)_construct_data can't be used for one-phase serialization, and that two phases (construction and serialization) are still needed. The original post by Dave said otherwise, though, and I think the misunderstanding comes from the example at
http://boost.org/libs/serialization/doc/serialization.html#constructors
where my_class serializes my_class::m *both* at my_class::serialize *and* my_class::(load|save)_construct_data. If the analysis I develop in my previous post is correct (is it?) this leads to my_class::m being serialized *twice* when a pointer to my_class is saved. Maybe it would sufice to rewrite this part of the documentation with a more sensible example like the one at test_non_default_ctor.cpp. What do you think?
I agree. The fact that the example uses a member variable confuses the issue. I'll amend the documentation accordingly. However, the current example does illustrate a case where it seems impossible to avoid serializing a member twice. One could leave it in the load_construct_data, and eliminate it from the serialization code - but then this would work only if the object was serialized via a pointer. If it were my program I would say hmmmm - I'm really confusing the role of the variable m - If its to be initialzed at construction - it shouldn't be messed with by serialization or operator= etc. If its realy part of the objects dynamic state - then it shouldn't be required at construction time. Anyway, I'll alter my example to make the variable in question "const" and remove it from serialization which is a better of example of the real cases where this can come up. Robert Ramey