The simple truth is I never consider this. When it came up the last time I didn't really think about it very much as I was involved in other things and I hoped intereste parties might come to a consensus without my having to bend my over-stretched brain. Austin Bingham wrote:
I saw a thread on this topic from a few months ago, and I was wondering if there had been any progress or new thought on the topic. Essentially, it appears that the serialization library can't reliably deserialize the serialized version of NaN and infinity for doubles and floats. This seems to be a result of relying on the, AFAIK, undefined behavior of writing NaN/infinity to a stream; it will work correctly with some standard library implementations, but not all.
I think the problem can be addressed with these changes:
basic_text_oprimitive::save(float or double): on NaN or Infinity, write out some known, stable string (i.e. "nan" or "inf"); don't rely on std implementation.
basic_text_iprimitive::load(float or double): look for the "known values" printed by save(), generating the correct values when they're seen.
I'm not convinced this would work very well. when loading a data value, you
have to know ahead of time what type its going to be - float or string.
Here are a couple random thoughts on this issue
a) I believe that native binary archives will handle this without out change
as they just copy the bits to the archive and back. As long as you read the
archive on the same compiler/os/machine, there should be no issue.
b)define a special type for Nan:
class NanType {};
Use variant serialization
ar << boost::variant