I have fixed the issue with boost::serialization::collection_size_type. Now it is handled explicitly. I simply cast it to uint64_t, which is one of the recommended choices. ("Recommended choices for a portable serialization of collection sizes are to use either 64-bit or variable length integer representation.") As stated previously - a problem may still arise when one try to serialize one of the common C (i.e. time_t, struct timeval) or OS (pthread_t, pid_t) types. They can be easily handled explicitly in a manner similar to size_t (and I think I will add this in future). On Tue, Dec 7, 2010 at 06:17, Piotr Trojanek wrote: > Oh, sorry. Now I have realized what you mean. In fact this can be an issue. > > I will check this more carefully and let you know. Thank you for pointing > out this! > > > On Tue, Dec 7, 2010 at 01:23, Troy Straszheim > wrote: > >> On Mon, Dec 6, 2010 at 4:05 PM, Piotr Trojanek >> wrote: >> > Yes, I have tested the archive with std::vector and it simply works. >> > >> > I guess it works also for any collection, which is supported by >> > Boost::serialization framework. >> > The magic is in the header, not in the >> > archive itself. >> > >> > For any primitive type always the same xdr_* function is called, so (by >> the >> > design of XDR) >> > it does not matter if the caller is 32 or 64 bit (nor if little/big >> endian). >> > >> >> Interesting. collection_size_type is std::size_t: >> >> BOOST_STRONG_TYPEDEF(std::size_t, collection_size_type) >> >> and in some implementations std::size_t is 'unsigned long'. If you >> then use this implementation on two platforms where >> 'unsigned long' have different sizes, you will get incompatible >> archives. In my experience with portable binary archives (we are >> going way back to boost 1.32), it was necessary to choose a size (e.g. >> handle collection_size_type explicitly and cast to uint64_t, for >> example). >> >> Cool archive, in any event. boost::serialization is incredibly useful >> stuff. >> >> -t >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> > > > > -- > Piotr Trojanek > -- Piotr Trojanek