Re: [Boost-users] [Serialization] How non-portable is the non-portableBinary Archive?

Subject: Re: [Boost-users] [Serialization] How non-portable is the non-portableBinary Archive?
From: Robert Ramey (ramey_at_[hidden])
Date: 2008-12-28 12:01:19

"James Madison" <jmadisondev_at_[hidden]> wrote in message 
news:8a5195f70812280234h46d2b464v36059c1f11713d58_at_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_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users