Boost logo

Boost :

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);

     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());
         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);

     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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at