On Oct 10, 2005, at 2:09 PM, Martin Slater wrote:
then I see several major disadvantages of this approach:
1.) it fixes the value types for which fast array serialization can be done
I worked around this by introducing an intermediary type ArchiveByteArray as follows
... struct BinaryArchiveByteArrayO { int count; const void *ptr; };
template<class T> BinaryArchiveByteArrayO MakeArchiveOutputByteArray(int count, const T *t) { BinaryArchiveByteArrayO res;
res.count = count * sizeof(T); res.ptr = t;
return res; }
There is a problem here: the type information gets lost once you create an BinaryArchiveByteArrayO, but the implementation of save (BinaryArchiveByteArrayO const&) will require that information in the case of XDR, MPI and other archives.
...
template<class U, class Allocator> inline void save( BinaryOutputArchive& ar, const std::vector<U, Allocator> &t, const unsigned int /* file_version */ ){ boost::mpl::if_<boost::is_pod<U>, Detail::VectorSavePodImp, Detail::VectorSaveImp>::type(ar, t); }
This is similar to the way I propose to implement vector serialization. Just look at the diffs I attached to my mail. The main difference is that instead of the mpl::if_ I use boost::enable_if.
This could probably have a dispatch mechanism above it checking for an archive trait to dispatch to either the fast or default implemention.
Exactly, a trait will be more flexible here, since your dispatch based on boost::is_pod<U> might be too narrow for some archives, and too broad for others (some such as XML archives might never want to support it). Matthias