From: Matthias Troyer (troyer_at_[hidden])
Date: 2005-10-10 07:31:52
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