
Then why cannot we use IEEE745 format for float serialization on all systems?
Because I don't think that the IEEE-754 internal format is as stable as you think it is. (Looking at Wikipedia's entries on IEEE-754 and 754r, there is a standard conceptual format, but problem is how do various implementations carry out the internal bit-wise format. Room for interpretation will doom your plan.)
Cannot we choose a stable, boost-specific format and consider all others incompatible? This is actually required if we are going to convert non-IEEE754 float numbers to a standard IEEE754 format by ourselves. I guess we can define a set of characterization float numbers and their standard binary representation in boost. Only those systems that represent these numbers in the standard way can be considered as IEEE754 compatible (subject to Big/Small Endian swap) and can be archived directly.
The string or "direct" conversions may introduce rounding errors.
I guess all string-based conversions have rounding errors. I am using a text archive for its portability and I think the situation will not be worse if I switch to an imperfect portable binary archive. Also, there might be platform specific loseless conversion methods...
Is it worth potentially screwing 0.01% of your customers when you may not have to?
I guess more than 0.01% boost/serialization users are suffering from not having a portable binary archive, I am one of them. Bo