Peter Dimov wrote:
Robert Ramey wrote:
Peter Dimov wrote:
When the author of X that has two fields x and y wants to serialize it into _any_ archive, he just "says" save(x) and save(y) to the archive.
However, the author of Y that contains an array currently can't just say save_array(a) to the archive, because save_array is not part of the current vocabulary. He needs to say save(a[0]), save(a[1]), ..., save(a[n-1]).
he needs to say save(a) that is ar << a. In any of the proposals the correct override will be invoked.
This only works for C-style arrays with the size fixed at compile time. Think about how one would write "save" for the following:
template<class T> struct my_array { T * data_; unsigned size_; };
OK - I depended on the [] indicating C++ arrays Take a look at the "Serialization Wrapper" concept as described in the manual. (The explanation is a little messed up but I'll fx that later). The basic idea is to define template<class T> struct nvp : public pair<const char *, T*> { .... // default implementation of serialize template<class Archive> void serialize(Archive &ar, const unsigned int){ // default implemention just throws away the tag name // and serializes the value ar & t; } .... }; text and binary archives don't have to do anything special regarding nvp - they just hand it off the serialization library as they do for anyother type. No save(nvp ... appears in any header other than in xml_archive. So the default serialization gets invoked for those archives. In xml_archives, there are save/load_override functions like the following. // special treatment for name-value pairs. template<class T> void save_override( const ::boost::serialization::nvp<T> & t, int ){ this->This()->save_start(t.name()); archive::save(* this->This(), t.const_value()); this->This()->save_end(t.name()); } This implements special behavior for the nvp type when used with the xml_archive. I invented this so I wouldn't have some special functions for xml having to be defined for all archives. It bothered me that binary_archive would have to "be aware" or implement anything related to xml. I think the same would work for arrays. define an array wrapper something like: template<class T> struct array { std::size_t & m_element_count; T & * m_t; explicit array(std::size &s, T & t) : m_element_count(s), m_t(t) {} // default implementation template<class Archive> void serialize(Archive &ar, const unsigned int){ // default implemention does the loop std::size count = m_element_count; T * t = m_t; while(0 < count--){ ar << *t; } } hpc_oarchive and/or its derivatives would contain something like the following. template<class T> void save_override( const ::boost::serialization::array<T> & t, int ){ this->This()->save_array(t.m_element_count, t.m_t)[ } Note this require refinement to deal with composition with other wrappers, compiler quirks, and things like that. I hope this doesn't obscure the main point. So the net effect is Everyone who want's to wrap his "arrays" in boost::serialization::array is free to do so. Archive classes which don't have special code for such arrays just pass it to the library by default which eventually resolves to an item by item serialization. Archives which have facilities suitable for handling arrays in a special way can overload save_override(boost::serialization::array ... and do thier thing. No currently existing archives need be changed. Archives which don't have special handling for these "array" (the majority) can completely ignore this facility. These will work exactly as before. It would mean that our current implementation of std::vector and C++ arrays would have to be altered to wrap the "arrays" but I could live with that. I already bit that bullet with nvp's. The main thing is that it avoids the that which I was most unhappy with - having to add something to all archive classes just to accomodate some special feature of one of them. Finally, it defines the "array-ness" of a data structure independantly of the the whole archive concept. That its "array-ness" becomes an optional feature of the data. This seems more "correct" to me. It certainly more in keeping with the spirt and design of the library to date. Robert Ramey