Serialization: how to port binary archives containing NAN created with version 1.43 to version 1.47?
Because of a user request we support serialization of nan and inf. The official boost archives don't, as you already found out. Robert Ramey wrote: I just looked at the page. It looks very interesting to me. When I have some time, I will be investigating which of these might be included in the boost distribution of the serialization library.
Does this mean that you plan to support IEEE special values (e.g. NaN, Inf) in boost, or some other part of Christian's work? There's traffic on the IEEE limitation (feature?) in boost::serialize dating back to at least 2005 --- some with your name on it! R
Robert Lupton the Good wrote:
Because of a user request we support serialization of nan and inf. The official boost archives don't, as you already found out. Robert Ramey wrote: I just looked at the page. It looks very interesting to me. When I have some time, I will be investigating which of these might be included in the boost distribution of the serialization library.
Does this mean that you plan to support IEEE special values (e.g. NaN, Inf) in boost, or some other part of Christian's work? There's traffic on the IEEE limitation (feature?) in boost::serialize dating back to at least 2005 --- some with your name on it!
R
Now I realize that the page had a number of things from different authors. Some I've looked at before (e.g. I'm curious about YAML). My position on the question about supporting different flavors of Nan is the following: a) The different flavors of NaN are not a problem in binary archives since whatever bits a float/double data item contain are saved and restored without checking them. Of course binary archives are not portable. b) For text archives, which ARE portable, this doesn't work because the underlying text stream does not write/read NaNs in a text format. This due only to the fact that the text archive implemenations build upon standard streams. c) If one want's to support serialization of different NaNs, the course is clear: implement a derivation of standard streams which add writing of NaN and reading thereof. Then use this extended stream as the argument when building a text archive. This is much simpler and more general than trying to role this functionality into the serialization library and would have utility way beyond the serialization library itself. I believe that code has been written and even checked in to implement this - though it has never been reviewed as far as I know. Robert Ramey
participants (2)
-
Robert Lupton the Good
-
Robert Ramey