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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk