Re: [Boost-users] Library Interface Design

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

On 9/13/06, Thomas Matelich <matelich_at_[hidden]> wrote:
> 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.

Ok, so I took a look at test_non_default_ctor*.cpp (from 1.33.1).  I'm
enlightened and confused.  It appears it will allocate memory for you,
or you can do two one-phase constructions if you want your object on
the stack.

I do find this test odd:
{ //...
    A a(4);
    ia >> BOOST_SERIALIZATION_NVP(a);

    A *pa1;
    ia >> BOOST_SERIALIZATION_NVP(pa1);
    BOOST_CHECK_MESSAGE(pa1 == &a, "Copy of pointer not correctly restored");

    A *pa2;
    ia >> BOOST_SERIALIZATION_NVP(pa2);
    BOOST_CHECK_MESSAGE(pa2 != &a, "Pointer not correctly restored");
//...
}

Mainly because I don't know why one would want/expect this behavior.
If someone has a short answer, I'd appreciate it, otherwise I'll
figure it out if I ever use Boost.Serialization.

Oh, and since I didn't change the subject, I agree with the others on
favoring one-phase construction.