serialization - portability
Hi! I'm having an issue with archive portability. As I'm quite new to the internals of boost, I hope my attempt at pinpointing the problem is sensible: #include <iostream> #include <boost/serialization/vector.hpp> int main() { std::cerr << boost::serialization::implementation_level <std::vector <long long> >::value << std::endl; return 0; } built on a x86_64 platform prints out "3", on a i386 platform it prints out "2". I tested this both with boost 1.33.1 and 1.34.1. It is my guess that it causes the serialization of the used type to result in a larger archive on x86_64 than on i386. (Which is the original problem that led me to discover this) So my question is: is this the result of a bug in boost? If not, then what is the explanation of this difference? Using linux-2.6 with gcc. Thanks, Stefaan
When the collections were first made, I made the decision that, for efficiency purposes, that collections of intrinsic types would have a lower implemenation level - no class information. This should be faster and I never expected the need for versioning. So in the standard .../serialization/vector.hpp there is something which sets the implementation level for these types. It would seem that "long long" matches to one type on a 64 bit machine and to a different type on a 32 bit machine, and that one of them maps to a type in one in the list of intrinsics. I'd have to think about the best way to handle it. Robert Ramey Stefaan wrote:
Hi!
I'm having an issue with archive portability. As I'm quite new to the internals of boost, I hope my attempt at pinpointing the problem is sensible:
#include <iostream> #include <boost/serialization/vector.hpp>
int main() { std::cerr << boost::serialization::implementation_level <std::vector <long long> >::value << std::endl; return 0; }
built on a x86_64 platform prints out "3", on a i386 platform it prints out "2". I tested this both with boost 1.33.1 and 1.34.1. It is my guess that it causes the serialization of the used type to result in a larger archive on x86_64 than on i386. (Which is the original problem that led me to discover this) So my question is: is this the result of a bug in boost? If not, then what is the explanation of this difference?
Using linux-2.6 with gcc.
Thanks, Stefaan
participants (3)
-
Hector C.
-
Robert Ramey
-
Stefaan