Re: [Boost-users] [serialization] Purpose of load_construct_data (was: Re: Library Interface Design)

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-09-16 14:03:08

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