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

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

> 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 construction
while 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-serialization
of objects which contain references to other objects as references can
only be set at object construction time.  Tracking would still work.

Robert Ramey

>
> leading to data duplication within the archive. This can be remedied
> by
> also overriding foo::serialize so as to do nothing, but then foo
> would be
> only serializable through pointers: serialization through instances
>
>   foo f(...)
>   ...
>   ar<<f;
>
> would do nothing!!
>
> The only way in which load_construct_data would have served purpose b)
> is if it had designed so that
>
> 1: the default implementation for load_construct_data was:
>   load_construct_data(ar,p){
>     ::new(p)T();
>     ar>>*p;
>   }
> 2: the default implementation for save_construct_data was:
>   save_construct_data(ar,p){
>     ar<<*p;
>   }
> 3: Through-pointer serialization only consisted of steps S(0) and L(0)
> and omitted L(1) and S(1)
>
> With this design, one would be able to override load_construct_data
> in the manner explained in serialization.html#constructors while
> retaining normal through-instance serializiation. As it currently
> stands, my view is that (save|load)_construct_data is not fit for
> one-phase deserialization.
>
> Am I missing something? I hope Robert has the time to comment on this.
>
> Joaquín M López Muñoz
> Telefónica, Investigación y Desarrollo