on Fri Aug 29 2008, "Robert Ramey"
Just to keep the pot boiling - here's my two cents.
a) Basically, floats can be represent as two integers. One for the exponent and one for a normalized fraction of one.
b) The C standard library provides functions which generate these two integers from any double (frexp) and retrieves the origninal double from the pair of integers(ldexp). I would guess that these functions are pretty efficient as they only return a subset of some existing bits.
c) the portable binary archive currently in the libraries handles integers in a portable manner. It has been tested on various platforms and already addresses issues such as what to do when on attempts to load an integer > 2^32 to a 32 bit machine. It also strips leading bits which don't add anything and makes the archives smaller.
It would seem using the standard functions - supported by any standard C library - and using the functionality already in portable_binary_archive, one could add floating point functionality relatively easily - and it would be no less portable than the C library is.
I wonder if it really works so well when the word size of the machines differs, or even when the word size is 32 bits on both ends. It's likely they're both using IEE754, so if long double has more than 32 bits of mantissa, your method will be needlessly lossy. I think long double commonly has 96 or 128 bits total, so you'd lose significant precision. The HPC community has had to solve this problem numerous times. These are people that care about the accuracy of their floating point numbers. Why one would begin anywhere other than with the formats the HPC people have already developed is beyond me. -- Dave Abrahams BoostPro Computing http://www.boostpro.com