[repost][serialization] version handling in {save|load}_construct_data
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
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
On Sat, Jan 9, 2010 at 11:19 AM, JOAQUIN M. LOPEZ MUÑOZ <joaquin@tid.es> 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
For note, your email was a big black blob on my black background. If you are going to specify a text color (black in your case), make sure you specify a background color (transparent in your case, which on my black background makes your text invisible). Better to just send as pure text anyway.
OvermindDL1 escribió:
On Sat, Jan 9, 2010 at 11:19 AM, JOAQUIN M. LOPEZ MUÑOZ <joaquin@tid.es> wrote:
[...]
For note, your email was a big black blob on my black background. If you are going to specify a text color (black in your case), make sure you specify a background color (transparent in your case, which on my black background makes your text invisible). Better to just send as pure text anyway
Thanks for the heads up. I usually send pure text messages only, seems my webmail client played tricks on me. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (4)
-
JOAQUIN M. LOPEZ MUÑOZ -
joaquin＠tid.es
-
OvermindDL1 -
Robert Ramey