From: Paul A Bristow (pbristow_at_[hidden])
Date: 2007-12-30 17:58:49
>[mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Ramey
>Sent: 30 December 2007 18:59
>Subject: Re: [boost] A question regarding serialization lib
>Paul A Bristow wrote:
>> The chances of this a very small 1 in 3 values of a very narrow
>I disagree with this. I don't think the chances are very small.
This is not conjecture - it was an observed behaviour as my original report shows.
It only emerged by accident - and was only confirmed by a random sampling of round-tripping values.
My understanding was that other compilers did NOT show this problem.
>> only MS is known to have this problem
>I don't think it's isolated to microsoft. I think it's an inherent
>limitation of trying to represent some binary fractions exactly as
I am confident from my investigation that it is failure to provide the *nearest* representable floating-point value from a decimal
digit string - but, bizarrely, only in a very small region, (IIRC from 0.0001 to 0.0005).
With this (as is provided by the C++ *compiler* standard when 'reading' decimal digit strings into floating-points like float,
double & long double), you can round-trip to decimal digit strings and back - provided of course that you use enough decimal digits.
But there is no similar requirement on reading with std:: iostreams, perhaps surprisingly (I think the authors assumed it but didn't
think to specify it).
(Of course, you can only expect 'round-tripping' to work if the floating point format is the same).
The same applies to lexical_cast.
So an answer to the first question: probably - but if the floating-point types differ, then all float-point value 'round-tripped'
will be a few bits wrong, and you might get a tiny proportion wrong for the reasons in my original (rejected) report to Microsoft.
--- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk