[boost] Re[serialization] problem deserializing vectors

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-09-30 09:13:53

Vladimir Prus wrote:

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

I believe you will when you try to load it. The library code doesn't
specifically address the const-ness of members.  Hence,  I 
believe that reading the value (save) will succeed while
writeing the value (load) will fail due to the const-ness.

>> 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.

>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.

Note that it is only requried to specify a default constructor if
a non-default one has been specified.  So in most cases the
issue won't even arise.

Suppose we tweak things to permit access to your default
private constructor.  In order for the program to link, V() wil
have to be defined.  If so what should m_i be initialized with?
Certainly, it shouldn't be left uninitialized.  Maybe some
default value should be provided.  But then, we should use

V(int i = 0) rather than V(int i)

and we dont' need a default private constructor and the program
compiles.

My real point is that the rules for default constructor are 
forcing us to think about what we're doing.  If we step
back a bit and consider what we're doing, The "problem"
will often go away. I think this is one case where C++
is saving us from ourselves.

class V {
public:
    V(int i = 0) : m_i(i) {}
    
private:
    int m_i;    
    
private: // serialization support
    friend class boost::serialization::access;
    
//    V() {}
    template<class Archive>
    void serialize(Archive& ar, unsigned version)
    {
        ar & m_i;
    }    
};

Robert Ramey