Serialization of infinite float
Hi,
I have run into a problem with the boost xml serialization of
overflowing floats. On Linux these are being serialized as 'inf' into
the xml files, but when reading the float back in it results in stream
errors. I have searched the archives to find an answer to this, but
without luck. The small program below has been compiled and run on
32-bit and 64-bit Linux (RedHat Enterprise Linux 4) with boost 1.33.1
and 1.34.1. In every case it results in a stream error and the float can
not be read back in from the xml file.
Does anyone know if this is supposed to work ?
#include <fstream>
#include
Arnstein Ressem wrote:
Hi,
I have run into a problem with the boost xml serialization of overflowing floats. On Linux these are being serialized as 'inf' into the xml files, but when reading the float back in it results in stream errors. I have searched the archives to find an answer to this, but without luck. The small program below has been compiled and run on 32-bit and 64-bit Linux (RedHat Enterprise Linux 4) with boost 1.33.1 and 1.34.1. In every case it results in a stream error and the float can not be read back in from the xml file.
Does anyone know if this is supposed to work ?
I had a similar problem (serialising NaNs - it turned out I had accidentally left some of my variables uninitialised), and there was a big discussion about serialising NaNs and infinities about a year or so ago. I seem to remember that the outcome was this could not be supported across all platforms, although I could be wrong. Could someone point this discussion out in the archives? Paul
This is a known issue with C++ standard i/o. It is only related to serialization to the extent that serialization depends upon C++ standard i/o. This comes up on a regular basis. I'm considering trappnig attempts to serialize NaNs as errors - as I think they always are. But then I would have to document the trap and how to override it as opposed to adding to the document why this is not a serialization issue. Robert Ramey Arnstein Ressem wrote:
Hi,
I have run into a problem with the boost xml serialization of overflowing floats. On Linux these are being serialized as 'inf' into the xml files, but when reading the float back in it results in stream errors. I have searched the archives to find an answer to this, but without luck. The small program below has been compiled and run on 32-bit and 64-bit Linux (RedHat Enterprise Linux 4) with boost 1.33.1 and 1.34.1. In every case it results in a stream error and the float can not be read back in from the xml file.
Does anyone know if this is supposed to work ?
#include <fstream> #include
#include int main() { const char fname[] = "float.xml";
float f = 1.0e+20*1.0e+20;
{ std::ofstream ofs(fname); assert(ofs.good()); boost::archive::xml_oarchive oa(ofs); oa << BOOST_SERIALIZATION_NVP(f); }
{ std::ifstream ifs(fname); assert(ifs.good()); boost::archive::xml_iarchive ia(ifs); ia >> BOOST_SERIALIZATION_NVP(f); }
return 0; }
Best regards, Arnstein Ressem
On Fri, Aug 10, 2007 at 06:19:47PM -0700, Robert Ramey wrote:
This is a known issue with C++ standard i/o. It is only related to serialization to the extent that serialization depends upon C++ standard i/o.
This comes up on a regular basis. I'm considering trappnig attempts to serialize NaNs as errors - as I think they always are. But then I would have to document the trap and how to override it as opposed to adding to the document why this is not a serialization issue.
My ideal would be for the serialization to catch it, and do some alternate "right thing(tm)". It is not uncommon for NaNs to be present in our data, and right now we are having to replace these NaNs with something else prior to serialization. If it weren't for the "human readable" requirement, we would probably have tried to switch to the binary archive. Jeff -- ---------------------------------------------------------------------------- "The man who does not read good books has no advantage over the man who cannot read them." -- Mark Twain ----------------------------------------------------------------------------
participants (4)
-
Arnstein Ressem
-
Jeffrey Brent McBeth
-
Paul Giaccone
-
Robert Ramey