Re: [boost] [serialization] Enhancing Archives with Archve Adaptors

From: Matthias Troyer (troyer_at_[hidden])
Date: 2005-12-07 05:51:47

Hi Robert,

In implementing your array wrapper proposal I encountered the two  
following issues:

The current version of the std::vector<T> serialization works also  
for non-default constructible types T since it does the following  
(version A):

     unsigned int count;
     ar >> BOOST_SERIALIZATION_NVP(count);
     s.reserve(count);

     while(count-- > 0){
         typedef BOOST_DEDUCED_TYPENAME Container::value_type type;
         stack_construct<Archive, type> t(ar);
         ar >> boost::serialization::make_nvp("item", t.reference());
         s.push_back(t.reference());
         ar.reset_object_address(& s.back() , & t.reference());
     }

On the other hand, any of the fast array serialization variants  
requires the type T to be default constructible
since deserialization would proceed as (version B):

     unsigned int count;
     ar >> BOOST_SERIALIZATION_NVP(count);
     s.resize(count);

     if (count)
       ar >> array(count,&s[0]);

Thus, the array wrapper can be used only for vectors of default- 
constructible types.

I see two ways how this can be implemented and wanted to discuss what  
option is best in your opinion:

i) the load function for std::vector could dispatch to either version  
A or B depending on the type traits has_trivial_constructor<T>

ii) one could leave std::vector serialization untouched, meaning  
always use version A, and use the optimized version B only in the  
archive wrapper for archives implementing fast array serialization.  
The advantage of this is that these archives know for which types  
they provide fast array serialization, and could override the  
std::vector serialization just for these types.

Also, as a second issue I want to bring up the size_type  
serialization issue again, since treating size_type different from  
unsigned int is essential for serialization of huge containers on 64- 
bit platforms, as well we for efficient MPI serialization. In  
previous exchanges this was found to be non-controversial and there  
was a consensus that a "strong typedef" will do the trick.

My question to you is now where such a strong typedef should be  
placed. The other strong typedefs (e.g. class_id_type) are all  
defined in the header boost/archive/basic_archive.hpp and in  
namespace boost::archive. Thus one option would be to define the  
size_type strong typedef also in that place. However, this will  
introduce a coupling between serialization and archive, since now the  
serialize functions for containers will have to include the boost/ 
archive/basic_archive.hpp to . I thus believe hat it would be closer  
to your design goals to define a size_type  wrapper ("strong  
typedef") in boost/serialization?

Matthias