Re: [Boost-users] [repost][serialization] version handling in{save|load}_construct_data
________________________________________ De: boost-users-bounces@lists.boost.org [boost-users-bounces@lists.boost.org] En nombre de Robert Ramey [ramey@rrsd.com] Enviado el: sábado, 09 de enero de 2010 21:40 Para: boost-users@lists.boost.org Asunto: Re: [Boost-users] [repost][serialization] version handling in{save|load}_construct_data
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.
I'm afraid that does not entirely answer my question. I understand what the "if(3 < ar.get_library_version()){" guard is for. What puzzles is me is why you need to explicitly save the type serialization version number when this info is seemingly recovered in other contexts without any explicit user operation. Let me put it another way: consider a user defined type my_type with associated serialization code: template<class Archive> void serialize(Archive& ar,my_type & m,const unsigned int version) { ... } When serialize() is called internally by Boost.Serialization, version is correctly passed without the user explicitly saving this info as it happens in the code for collection serialization. Why this difference? Am i making myself clear as to what the root of my puzzlement is? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
I'm afraid that does not entirely answer my question. I understand what the "if(3 < ar.get_library_version()){" guard is for. What puzzles is me is why you need to explicitly save the type serialization version number when this info is seemingly recovered in other contexts without any explicit user operation. Let me put it another way: consider a user defined type my_type with associated serialization code:
template<class Archive> void serialize(Archive& ar,my_type & m,const unsigned int version) { ... }
When serialize() is called internally by Boost.Serialization, version is correctly passed without the user explicitly saving this info as it happens in the code for collection serialization. Why this difference? Am i making myself clear as to what the root of my puzzlement is?
OK - I think I understand the question now. I looked back through the SVN and it only went back to 2007 and the change was already in there. So the truth is that I don't know the answer. Even so, I'm going to hazard a guess. The binary_archive have the facility to stream whole collections as a group. This applies to arrays and vectors and perhaps other collections yet to be defined. This facility will be used if the items in the collection are of a type "is_bitwise_serializable". This can save huge amounts of time. But it bypasses the normal serialization so the version# and other traits are lost. I believe this bit of code was used to remedy the situation. Looking at the code I can't see how it does this - but I'm pretty sure that that was the motivation and that it addressed the problem. That's all can I can say without delving more deeply into it. It's possible that mining the old list might shed some more light on it. Robert Ramey
I investigated a little bit more. Seems that save/load_construct data needs the version # and there is no place else to get it. There might well be something wrong in all of this. But it would require a significant effort to track it down. Robert Ramey
participants (2)
-
JOAQUIN M. LOPEZ MUÑOZ -
Robert Ramey