|
Boost : |
From: Johan Råde (rade_at_[hidden])
Date: 2006-08-01 10:48:49
Paul A Bristow wrote:
> For the record, as a punishment for raising this issue at the UK C++ BSI
> group meeting, I was tasked with raising the issue for the C++ Standards
> group.
>
> Some rambling thoughts on this issue are at
>
> http://www2.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2022.pdf
>
> Your implementation almost certainly provides a 'proof_of_concept' for this
> - as if it was needed.
>
> And I suspect more than a few will be well advised to use it - otherwise
> they may find to their cost (possibly considerable cost) that some archives
> turn out to be not readable because some floating-point calculation has
> produced an infinity or NaN.
>
> If you don't do this, it would seem prudent to ensure that every
> floating-point serialized is checked for finiteness before writing to the
> archive, and worrying about what to do it any are not!
>
> Thanks.
>
> Paul
>
I read your document. It seems that we have reached more or less the
same conclusions about the representation of inifinites and nan in text
streams. :-)
Thanks for informing me that there is a C99 standard in this area.
As a VC++ 7.1 user, I have never used C99.
I note that:
The output from the extended_num_put facet is consistent with the C99
standard, except that I do not put signs on NaNs. I will not change
that, since there is no reasonable way for a C++ program to detect that
sign. (And the sign has no meaning anyway, unlike infinity where a sign
sometimes, but not always, does have meaning.)
The extended_num_get facet should probably be modified to accept as
input all the representations allowed under the C99 standard. This means
adding support for
1. infinity as an alternative to inf
2. +nan and -nan
3. nan with extra info, i.e. nan(...some characters...)
Thanks,
Johan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk