David Abrahams wrote:
"Robert Ramey"
writes: David Abrahams wrote:
This would be a good thing from my standpoint as up until now a NaN could be saved but not recovered as the standard text stream input chokes on the Nan Text.
Seems like you should work around that problem.
If it indeed it is a problem.
I don't know what to say. If I, as a client of your library, say the lack of this functionality would represent a problem for me, and you doubt the truth of it, it seems the discussion is over.
I haven't yet read the later messages, but from my point of view (a typical user), the bottom line *must* be: 1. If you can legitimately write it to an archive, you *must* be able to read it it back in. If not, the archive is useless, and the library is buggy. 2. Conversely, if you cannot legitimately read it, you must *not* allow it to be written out - throw an exception or handle it in some other way, but you *must* advise the user somehow. If not, the library is buggy. This applies to NaNs as much as to uninitialised booleans or anything else. The weight of argument so far seems to be that allowing NaNs to be written and read is a good thing. I'm sure it wouldn't be too hard to get the deserialisation code to parse NaN as a legitimate value for a floating-point variable. Paul