I believe that this came about when error to the serialization of collections was discovered. Previous library versions didn't properly save the version of the collection item. When this was corrected, this code was needed to permit the the loading of archives created previously. If the type isn't versioned (e.g. some primitive type), then the default version # would be zero. I suppose this could be made more elaborate so that the version # wouldn't even be in the archive in these cases - but that's not way we did it. I don't know if that answers your question, but that's what I remember about it. Robert Ramey
Why the version number has to be given such manual processing when this is not needed if, for instance, serializating values via the simple ar&value?
JOAQUIN M. LOPEZ MUÑOZ wrote:
Hello, allow me to repost this message from a couple of weeks ago:
I've taken a look at how the version number is dealt with in Boost.Serialization collection serialization code:
* The relevant code at saving time is:
if(3 < ar.get_library_version()){ const unsigned int item_version = version< BOOST_DEDUCED_TYPENAME Container::value_type >::value; ar << BOOST_SERIALIZATION_NVP(item_version); }
* At loading time, the equivalent code is:
unsigned int item_version; ar >> BOOST_SERIALIZATION_NVP(count); if(3 < ar.get_library_version()) ar >> BOOST_SERIALIZATION_NVP(item_version); else item_version = 0;
Can someone (aka Robert :-) ) shed some light on this bit? Why the version number has to be given such manual processing when this is not needed if, for instance, serializating values via the simple ar&value? I'm trying to do the equivalent thing in Boost.MultiIndex.
Thank you,
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users