"James Madison" <jmadisondev@gmail.com> wrote in message news:8a5195f70812280234h46d2b464v36059c1f11713d58@mail.gmail.com... I am interested in using boost serialization for a project I am currently working on, but two requirements are hurting me. First, the archives have to be portable. Second, it's critical to keep the message size under a certain threshold which the text archives blow through. *** It's not at all clear to me that a binary archive would be smaller than the corresponding text archive. For example, a integer with a value 0 consumes 2 bytes in any text archive but 4 bytes (32 bits) in a binary archive. So data with lots of 0 values would generate a much larger binary archive than a text archive. binary archives would be expected to be faster in all cases. So I am wondering if I can somehow get away with using a binary archive, even though my choices seem to be a non-portable version, or a unsanctioned tested version. Oh, and I am pretty much stuck using Boost 1.32. So, basically, I am wondering: 1. How non-portable is the non-portable archive? While this is a mixed windows/linux environment, all the computers are running as x86 or x86_64, so the endian is the same and word boundary restrictions are mostly the same. *** "mostly?" - lol - then it would "mostly" work. I doubt that things would be satisfactory. I would think than on a 64 bit machine pointers would be - 64 bits - while on a 32 bit machine - 32 bits. This would make things fail. Unfortunately, the mapping of data types might not be the same. Is there a simple way to test this if the answer is "maybe"? *** my personal view is that this kind of testing is counter productive. 2. How stable is the portable archive? Reading through the release notes for 1.37 it seems like that the code is solid, except for encoding doubles, which would not be a problem. Of course, I am being forced to use 1.32, which might be much more unstable . . . *** curent portable binary is well tested. You'd have to tweak it a little bit - but not much - to make it work with 1.32. Thanks in advance for any replies. *** "it's critical to keep the message size under a certain threshold" This is the key issue that's driving your interest. I think a better approach would be to ask yourself what this restriction is really about? If its truely just message size, then the best would be just to use a stream_buffer which incorporates data compression. Machines are so fast these days that the time cost of implementing compress/decompress is more than compensated for by the time saved in data transmission or reading/writing to disk. Robert Ramey _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users