Re: [boost] [serialization] How are floating point values handled?

Subject: Re: [boost] [serialization] How are floating point values handled?
From: John Maddock (john_at_[hidden])
Date: 2013-08-08 12:11:25

>> The issue would presumably also surface if someone tried to
>> non-intrusively support non-standard native floating point types such
>> as GCC's __float128 or Intel's _Quad data types, you can write a
>> "serialize" function instead, but as you already pointed out, that
>> involves more typing once you you split the method into load/save and
>> binary/text variants.
>
> then it would seem to me that the basic_text_oprimitive.hpp should
> be enhanced to conditionally support these types.  This shouldn't
> be very hard as long as these plaforms already support stream
> i/o of these types.  (somehow I doubt they do).

You're right, I don't think they do yet, you have to call special C routines 
in libquadmath.  I just used them as examples that easy extensibility is a 
good thing.

> But then you've
> not lost portability of the text_?archive.  Soooo how about if you
> leave your mp types a prinitive types and portable implement
> steaming operators for them?  You could then address the
> round tripping issue to your taste.  And besides, don't you need
> to do this anyway so users can display/input your new types?
> So wouldn't the serilization come for free here?

Sigh.   My MP types already have streaming operators, and as they're 
supposed to, *they honor the current stream precision*, and in the current 
serialization code that means they see either a requested precision of 5 
digits (the default), or else whatever precision the stream may have been 
left in after serializing a float/double etc.  Same issue with long double 
which doesn't currently have a text-archive-save-overload to set the 
precision.  I'm suggesting a generic solution in the generic primitive-save 
code would be better.   I'll try and post a patch.

John.