From: Matthias Troyer (troyer_at_[hidden])
Date: 2002-03-01 17:28:20
On Friday, March 1, 2002, at 11:14 PM, rameysb wrote:
> b) using text is ZERO effort - using XDR or some other scheme
> requires significant programmer effort.
only once a couple of hours for one library writer
> c) I doubt that any such scheme is more robust than using the
> functions from the standard library.
we've used it for 8 years in production codes, for thousands of years
of CPU time on many machines, no problems.
> 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 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.
for our typical 7-8 digit integers it's a factor of two
> So here is my summary. Rankings from most to least desirable are:
> portability - text, portable_binary, native
> programming effort - text, native, portable_binary
> archive size - native, portable_binary, text - application dependant
> execution speed - native, text/portable_binary (depends on
> As no option is ranked first in every catagory, and different
> applications have different priorities - there is no way that there
> can be universal agreement on this point.
> I am currently making changes that will implement iarchive and
> oarchive as base classes. while the specific types will be handled
> through virtual functions.
that's what we use at the moment too.
> This wll permit any application to use his preferred format with no
> I hope this will adddress the issue
I agree and look forward to the new version,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk