Matthias Troyer wrote:
---------------------------------------------------- template<class Base, class T> void save(boost::archive::bitwise_oarchive_adaptor<Base> &ar, const std::valarray<T> & t,) { const unsigned int count = t.size(); ar << count; save_array(ar, get_data(t),t.size()); }
----------------------------------------------------
Hmmm - did you perchance mean to use "bitwise_oarchive_adaptor<Base> in the above ? Changing the names a little bit for clarity, I always anticipated archive developers would use something like the following: template<class T> void save(boost::hpc_archive &ar, const std::valarray<T> & t...) { const unsigned int count = t.size(); ar << count; save_array(ar, get_data(t),t.size()); } This would apply the save_array enhancement to all classes derived from hpc_archive. In fact I would expect that this is the way people are doing it now. The only problem with this was that it would only apply to one "family" of archives - those sharing a common base class. In particular it wouldn't apply to binary_oarchive. Previously, you raised the concern that code like the above would have to be replicated in order to add enhancements for different archives - particularly binary_oarchive. So that is my motivation for suggesting the "archive adaptor" approach. But as it turns out - you won't be using binary_oarchive in any case. Dave left the same class name but put it in a different namespace but in fact it will be a different archive - if for no other reason that to avoid backward compatibility issues with currently existing archive data. Besides this seems pretty clear that stream i/o is not the highest performance solution so you won't be deriving from the current binary_primitive either. So with a little renaming I would anticipate that things would look like class hpc_oarchive : public .... { ... all the stuff in daves oarchive }; class mpi_oarchive : public hpc_archive { ... implementation for mpi }; class xdr_oarchive : public hpc_archive { ... implementation for xdr }; etc. In this case the simple overload above would be fine. its applied to he base class - its automatically applied to all the deriviations. The only thing "missing" is that its not applied to the current binary_oarchive. But I don't think that is an issue anymore. If it is - its outside the context of the high performance computing archive (hpc_oarchive) and if someone is interested, he can apply my adaptor. So all the "enhancements" can be applied without requiring changes in the core library and without requiring serialzation authors to be aware which enhancements need to be used with which archives. This is the view I've advocated from the beginning. Robert Ramey