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.