[boost] [serialization] load_construct proposal

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-10-12 16:49:56

Below I will try to summarize the argument
on this thread.  I believe that mixing of unrelated
issues has been very confusing.

Here is the current default implementation:
/////////////////////////

template<class Archive ar, class T>
void load(Archive & ar,  T * &t,  unsigned int file_version)
{
    t = NULL; 
    try{  
       t = new T();
       ar >> *t;
    }
    catch(...){
        delete t;
        throw;
    }
}

Here is Dave Harris's proposal:
/////////////////////

template<class Archive ar, class T>
void load_construct(Archive & ar,  T * t,  unsigned int file_version)
{
    new( pt ) T(); // Default-construct in place
    ar >> *t;    // presumably
}

// the following would not be part of the public interface.

template<class Archive ar, class T>
void load(Archive & ar,  T * &t,  unsigned int file_version)
{
    t = NULL; 
    try{  
       p = static_cast<T *>(new char[sizeof(T)]); // allignment issues?
       load_construct(ar, static_cast<T *>vp, file_version)
    }
    catch(...){
        delete t; // hmm - what about dtor? 
        throw;
    }
}

The current system

1) simpler - transparently correct
2) permits any required overload
        a) memory allocation
        b) construction
        c) exception handling.
3) maintains analogy with save/load nomenclature for seialization of objects.

Your proposal

1) is not as transparently correct.
2) raises issues as to inplace construction alignment.
3) without making the public api larger, does not permit
        a) override of memory allocation
        b) overide of exception handlling
4) replace overriable functions save/load with  save_construct/load_construct.
These don't convey meanings of what they do. ( what could save_construct
possibly mean?)

Note that this issue has absolutly nothing to do with the ability to override
and/or access private default constructors.  Both systems use the default
constructor as the er... default constructor. Both systems require the
user to specifiy an override if there is no default constructor.  Neither system
currently permits access to a private default constructor.  I will address the
issue of access to a private constructors - default or otherwise in a
separate post.

So, in light of the above, I'm not convinced that any change would be beneficial.

Robert Ramey.