[boost] Re[serialization] problem deserializing vectors

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

I've looked more carefully at the code and now believe that
this the implementation in vector.hpp could be tweaked
to access even a private default constructor.

I still have a lot of reservations about actually doing so
however.

I can't shake the idea that C++ designers are trying
to tell us something when this won't compile.  That's
precisely why the language rule is " a default 
constructor if and only if there is no other constructor
supplied".  

If I have defined ( not just declared)

V()

as well as

V(int i)

Then what am I saying.  One needs an integer to 
construct a valid V.  This would suggest a default
constructor can't return a valid V. When we find that we need
a default constructor to permit serialization we
want to say "Oh I want to make an exception
for the serialiation system as I happen to know
that it will reload m_i "

Well, I guess that's ok.  I want to make an
exception for serialization then I can add

friend struct boost::serialization::stl::archive_input_seq;

thereby making special exemption for serialization.

On the other hand in this case I would prefer
not adding a default constructor but making a custom serialization
for vectors of type V as

template<class Archive>
void load(
    Archive & ar, 
    std::vector<V> & v_collection, 
    const unsigned int version
){
    // retrieve number of elements
    unsigned int count;
    ar >> count;
    v_collection.clear();
    v_collection.reserve(count);
    while(count-- > 0){
        int i;
        ar >> i;
        V v_element(i);
        ar >> v;
        v_collection.push_back(v);
    }
}

This preserves the invarient that no invalid instance of V can
ever exist. 

 I think this kind of approach which I call
"Building Bugs Out(tm)" is one of strongest features of C++
for building correct and "unfragile" programs.

Either of the above solutions permits me to make exceptions
on a case by case basis.  I if tweak the system to permit
transparently permit access to private default constructors
I'll be depriving myself the notice that I may well have done
something that I would really like to think about.

Another reservation I have about making the change is
that so far, the library has been uncoupled from the
serializations included with the library.  That is, there
is no code in the serialization library that is tied
to any particular serialization. And the serialization
implementations included, e.g. vector.hpp don't use
any special access to serialization other than the 
published API.  Making this change - though its small -
would entail making vector serialization a friend of
boost::serialization::access.  This would couple
the serialization library to a particular usage of
serialization.  It would also mean that from now on
boost::serialization::access would have to be constantly
updated as as other library serialization is implemented.
Another situtation I would very much like to avoid.

This is a fairly large package composed of a number of
semi-autonomous parts:

serialization
        tracking
        class_info
archives - depends on
        one template function in "serialization"
        serialize
        save
        load
sample/serializaitions
        stl collections
        auto_ptr
        shared_ptr (in coming draft)

The only reason the library has arrived to this stage
is that I've been able to keep these things de-coupled
so far.  I would very much like to keep it that way.

Robert Ramey