I would have thought it would be better for the serialization lib to set the stream precision before outputting a primitive type - to std::numeric_limits<T>::max_digits10 (or std::numeric_limits<T>::digits10+2 if max_digits10 is not available). However, I recognize that this is a difficult issue!
lol - thanks for recognising that this is a difficult issue. It is reported on a regular basis.
binary_?archive - no issue.
portable_binary_archives - doesn't support floating point numbers.
text archives - this depends on the std::stream to do the the conversion to text and back again. It uses functions in this class to attempt to set the precision to high enough number so that no more information is lost than is necessary. Conversion to text and back again has some inherent problems. Note that these have their root cause in the std::stream implementations and design rather than the serialization library itself.
a) there is not necessarily a one to one mapping of every ieee 754 number with a binary mantissa to a decimal representation.
My view is that on who relies on perfect round tripping of a floating point number is making a design mistake. Leave aside the fact that it cannot be portable between machines with different floating point representations (and precisions). It conflicts with what a floating point number really is. It's an attempt to capture some continuous value to finite level of precision. It generally represents some physical quantity which generally can only be measured to a precision less than that which our floating point representation can represent. So I've very suspicious of any program which requires perfect round tripping - if our program depends on having more precision than that which can actually be measured - what can theh program actually mean?
Point taken, however it is technically possible to achieve perfect round tripping: which is to say both decimal to binary and binary to decimal conversions round to nearest. It is however hard to achieve, requires arbitrary precision arithmetic (yes even for float/double) and isn't what all std lib's do: msvc being the main culprit here.
b) compilers/libraries don't handle NaN in a consistent way so handling these is inherently non-portable.
I think I address this by trapping whenever one tries to serialize a NaN. My reasoning was that it was a pain to implement, and would be unreliable. I also feel (and felt) that anyone actually trying to do this is making a mistake and should think about what he's really doing. (I caught hell for say this - anyone who does this doesn't know what he's doing. Maybe it was the way I phrased it - oh well).
It sounds reasonable in most cases - however there are situations when a genuine NaN might be required - an example might be where you have a table of statistics, and a NaN is used to indicate "no data". John.