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

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2006-09-16 12:49:40

Hello Robert,

----- Mensaje original -----
De: Robert Ramey <ramey_at_[hidden]>
Fecha: Sábado, Septiembre 16, 2006 9:00 am
Asunto: Re: [Boost-users] [serialization] Purpose of
        load_construct_data	(was: Re: Library Interface Design)

> > I am not sure. I'm a little puzzled about the intended purpose of
> > load_construct_data, as the docs and the code of Boost.Serialization
> > seem to suggest that it is used for two incompatible tasks:
> >
> > a) to construct a dummy object prior to deserialization itself, thus
> > providing a user-overridable hook in case default construction 
> is not
> > appropriate.
> > b) to deserialize in place as explained on the bit you quote.
> >
> 
> The intended purpose was to address de-serialization of objects
> that have no default constructor.  See test_non_default_ctor.
> 
> > My hunch is that Robert started this with b) in mind but finally the
> > facility was kept playing a more humble role as a). Consider for
> > instance, serialization of pointers: currently, if an object 
> instance> is saved exclusively through pointers, 
> Boost.Serialization does the
> > following when the first such
> > pointer is met
> >
> >   save_construct_data(ar,p); // S(0)
> >   ar<<*p;                    // S(1)
> >
> > and correspondingly at loading time
> >
> >   p=get unitialized storage;
> >   load_construct_data(ar,p); // L(0)
> >   ar>>*p;                    // L(1)
> >
> > By default save_construct_data does nothing and load_construct_data
> > creates a default cted object, effectively leading to a two-phase
> > construction scenario. Now, if the user decides to override
> > (save|load)_construct_data
> > for some class, say foo, so as to perform one-phase construction,
> > we've got the following:
> >
> >  S(0) saves foo contents
> >  S(1) saves foo contents again
> 
> Nope.  save_construct_data saves ONLY that data needed for 
> constructionwhile ar << *p save that data NOT used in construction.
> 
> >  L(0) loads foo contents and creates a foo object with these.
> >  L(1) loads foo contents again
> 
> Nope - see above.
> 
> I believe this is well illustrated by the 
> test_non_default_ctor.cpp example
> previously cited.
> 
> Note that in generally, the data required to construct an instance 
> might not
> be part of the instance itself. This is also addressed by this api.
> 
> I'm not sure, but I suspect this could be also useful in de-
> serializationof objects which contain references to other objects 
> as references can
> only be set at object construction time.  Tracking would still work.
> 

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?

> Robert Ramey

Thank you,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo