Re: [Boost-users] Library Interface Design

From: Thomas Matelich (matelich_at_[hidden])
Date: 2006-09-13 13:17:48

On 9/13/06, David Abrahams <dave_at_[hidden]> wrote:
> "Thomas Matelich" <matelich_at_[hidden]> writes:
>
> > On 9/13/06, David Abrahams <dave_at_[hidden]> wrote:
> >> Jeff Garland <jeff_at_[hidden]> writes:
> >>
> >> > Loïc Joly wrote:
> >> >> Jeff Garland a écrit :
> >> >
> >> >>> Oliver is correct -- serialization does not require default constructors for
> >> >>> the types.  It does require a constructed object prior to reading in the data.
> >> >>
> >> >> Yes, you are right. My mistake.
> >> >>
> >> >> What I meant is that for deserialisation, you still have a two phases
> >> >> construction: First, build your object with any mean available (if your
> >> >> object have only constructors with non-default parameters, this will
> >> >> probably imply building them with dummy parameters), then, in a second
> >> >> phase, override the member values by the serialized version.
> >> >
> >> > Yep.
> >>
> >> Nope.  Sorry to be blunt, but I just want to make absolutely sure this
> >> isn't missed:
> >>
> >> http://boost.org/libs/serialization/doc/serialization.html#constructors:
> >>
> >>   template<class Archive>
> >>   inline void load_construct_data(
> >>       Archive & ar, my_class * t, const unsigned int file_version
> >>   ){
> >>       // retrieve data from archive required to construct new instance
> >>       int m;
> >>       ar >> m;
> >>       // invoke inplace constructor to initialize instance of my_class
> >>       ::new(t)my_class(m);
> >>   }
> >>
> >> One phase construction.
> >>
> >
> > I poked around in the link you posted, but I don't see any examples of
> > a my_class getting serialized into.
>
> That's exactly what's happening above.
>
> > Where does t come from?
>
> It's memory allocated for you by the serialization library I suppose.
>
> > IOW, how do I call this without passing dummy information into a
> > my_class object?
>
> t isn't passed into the my_class; it's just raw memory with suitable
> alignment.
>
> > I'm sure I'm missing something, but all I can envision is a
> > reinterpret_cast of a void*/malloc.  Or two one-phase constructions.
>
>   new(t) X(m)
>
> constructs a new X object in the memory at t, passing m as the one
> ctor argument.
>
> Does that help?

Not really.  I get the new(t) part, I guess I'd just like to see to
client code, likely due to my denseness.  Maybe I'll go look in the
serialization unittests.