"James Madison" 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
