John Maddock wrote:
Ah... my problem was with a UDT that was marked as a primitive: then it just calls the << operator and doesn't attempt to set the stream precision as far as I can tell?
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). 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? Robert Ramey