Re: [boost] A question regarding serialization lib

From: Edward Diener (eldiener_at_[hidden])
Date: 2007-12-30 16:14:51

Paul A Bristow wrote:
>  
> 
>> -----Original Message-----
>> From: boost-bounces_at_[hidden] 
>> [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Ramey
>> Sent: 30 December 2007 16:53
>> To: boost_at_[hidden]
>> Subject: Re: [boost] A question regarding serialization lib
> 
>> I would expect that in your test text1.doc would be identical 
>> to text2.doc.
>>
>> UNLESS you have have floats/double in your classes.  In 
>> general, it cannot
>> be guarenteed that there is a one-to-one correspondence 
>> between floatiing
>> point values as represented by binary in ram to text numbers 
>> represented
>> as decimal based text.  So in this case I would expect text1.doc to not
>> be identical to text2.doc.
> 
> The chances of this a very small 1 in 3 values of a very narrow range- and only MS is known to have this problem as the link below
> shows.
> 
> The following feedback item you submitted at Microsoft Connect has been updated:
> 
> Product/Technology - Visual Studio and .NET Framework
> Feedback ID - 98770
> Feedback Title - Decimal digit string input to double may be 1 bit wrong.
> 
> The following fields or values changed:
> 
> Field Status changed from [Resolved] to [Closed]
> 
> To view these changes, click the following link, or paste the link into your web browser:
> 
> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98770 (requires sign-in)
> 
> Amazingly (to me at least) this is a 'feature' and may not be fixed - despite it looking very much like a simple out-by-1 error.

What is most amusing is that under .Net there is actually a format 
specifier ('r') for converting a .Net String to and from a double which 
guarantees that the textual representation will stay exactly the same. 
Yet at the same time you are told in response to your report that
"Round-tripping through all the machinery of input and output passes 
through various representations, and cannot be guaranteed to be 
identical to the original."

However I did not see a way of guaranteeing this in native C++ under VC++.