Re: [Boost-users] Library Interface Design

13 Sep 2006

      On 9/13/06, Thomas Matelich  wrote:
...
On 9/13/06, David Abrahams  wrote:
...
"Thomas Matelich"  writes:
...
On 9/13/06, David Abrahams  wrote:
...
Jeff Garland  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.