From: Rainer Deyke (root_at_[hidden])
Date: 2002-03-01 18:14:04
----- Original Message -----
From: "rameysb" <ramey_at_[hidden]>
Sent: Friday, March 01, 2002 3:14 PM
Subject: [boost] Re: Serialization (Persistence) library draft
> What's the difference:
> a) As far as the portability of the data there is no difference.
> b) using text is ZERO effort - using XDR or some other scheme
> requires significant programmer effort.
Text may seem to take less effort because the standard library already
handles formatted text i/o. However, implementing serialization in
terms of formatted text i/o may in fact take more effort than
implementing it from scratch would, especially if the serialized form
is supposed to be native text. For example, a 'std::string' object
may contain spaces (treated as separator by formatted i/o), newlines
(ditto, and also stored as different character sequences on different
platforms), characters with the high bit set (not part of 7-bit
ASCII), and null characters. Handling all of these cases probably
already requires more code than my entire portable binary
> c) I doubt that any such scheme is more robust than using the
> functions from the standard library.
Given that a serialization library built on top of the standard
library formatted text i/o is not necessarily simpler than a custom
serialization library, it is also not necessarily more robust.
> d) Execution time. I would expect be a gain storing/loading to/from
> a native binary mode. But if you're going to transfer to between
> native and canonical form its going to depend upon how much effort
> was expended in the implementation. One can't say apriori that
> a on particular canonical form is necessarily faster than any other.
A canonical form designed for performance is almost certainly faster
than one designed for human readability in almost all cases.
> e) Archive size. XDR fills out 32 bit integers to 4 bytes. In text
> mode any integers less the 100 take only 3 bytes.
I have seen binary formats that store integers less than 128 in a
single bytes. The tradeoff is that large 32 bit integers may require
5 bytes and the system is somewhat slower and more complex.
> I don't know if
> XDR handles 64 bit integers but if it does presumable it fills out 8
> bytes per integer. I would expect that text files are large in
> general but by how much would depend on the particular data.
Note that XDR files are still smaller after compression in most cases.
> portability - text, portable_binary, native
I would switch text with portable_binary here.
> programming effort - text, native, portable_binary
I would place text last here.
> archive size - native, portable_binary, text - application dependant
Native isn't necessarily smaller than portable_binary.
> execution speed - native, text/portable_binary (depends on
Text is almost certain to be much slower.
-- Rainer Deyke | root_at_[hidden] | http://rainerdeyke.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk