[boost] Re: Re[serialization] problem deserializing vectors

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-09-30 01:02:59

Robert Ramey wrote:

> I've considered your example in more detail and now feel I can
> shed some light on it.
> 
> suppose we have:
> 
> class A
> {
> private:
> const m_i;
> A();  // make default unavailable
> public:
> A(int i) : m_i(i);
> };
> 
> What does the following mean?
> 
> boost::archive::text_iarchive oa;
> A a2(2);
> oa << a2;
> 
> boost::archive::text_iarchive ia;
> A a1(1);
> ia >> a1;
> 
> should the m_i member variable of a1 equal 2 or should it
> equal 1.
> 
> In this system it will equal 1 and I think that is correct.
> A const member is shouldn't be changed by any operation
> (otherwise we wouldn't have made it "const").  The same
> argument can be made for any constuctor intialization
> arguments - that is that they are part of the "permanent"
> state of the object.

Will I get any error if I serialize this 'const' member?

> On the other hand if we do the following
> boost::archive::text_iarchive oa;
> A a2(2);
> oa << & a2;  // serialize as a pointer
> 
> boost::archive::text_iarchive ia;
> A *a1;
> ia >> a1;
> 
> then a1.m_i wil be in fact equal to 2 - is this wrong?
> I don't think so as we're talking about a new object
> as opposed to an already created one whose state
> we want to restore.

Ok, that's fine.

> Moving on to collections of objects.
> 
> my current implementation of serialization of
> vector<T> clears the vector and for each element
> of the vector creates a new one and de-serializes
> to fill the contents.  Maybe this conflicts with
> the discussion above.  STL containers elements
> are required to implement an assignment operator.

But note what while container elements must be CopyConstructive and
Assignable, they are not required to be DefaultConstructible. IOW, it's OK
to put class with private default ctor into a vector.

> This suggests to me that there is a conceptual
> conflict inherent in the idea of an STL container
> of objects that require construtor arguments.
> 
> Anyway, the answer to your question is
> 
> a) the serializations included with the library presume
> the existence of a default constructor.

That's fine with me. But, why don't allow default ctor to be private?
All the machinery needed to access that ctor is already there.

> b) If this doesn't apply to your specific case you
> can supply your own implementation rather than
> use the default one included.

The problem is that I really like that I can make default ctor private. I
rarely declare default ctor, and would not like to add it to public
interface, just for the sake of serialization.

The example you give directly uses non-default ctor. I agree this might be
necessary in some cases, but in my case, it would be much simpler if I
declare default ctor as private and serialization lib access that ctor.

> I believe you were working with gcc 3.3 on linux.  Is
> this correct?  Have you been able to compile and link the
> tests.  I'm curious about this as my gcc 3.2 cygwin
> system doesn't support wide characters and the XML
> tests fail on my system.

I'm sorry that I did not run the tests yet --- I was more interested in
trying serialization as applied to my project. I'm running the tests now
and will report the results later.

- Volodya