Re: [Boost-bugs] [Boost C++ Libraries] #9177: Improved serialization of floating point values

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #9177: Improved serialization of floating point values
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-10-26 22:12:21

#9177: Improved serialization of floating point values
  Reporter: johnmaddock | Owner: ramey
      Type: Bugs | Status: closed
 Milestone: To Be Determined | Component: serialization
   Version: Boost Development Trunk | Severity: Problem
Resolution: fixed | Keywords:
Changes (by ramey):

 * status: new => closed
 * resolution: => fixed


 I've incorporated this patch into the code. A couple of observations

 a) user types such as a multi-precision float would need to implement the
 << operator or trigger a compile time error.

 b) the serialization_trait for these types must be marked "primitive" in
 order to get to the correct code.

 c) and of course these special types need to corresponding members defined
 in numeric_limits.

 Failure to get the above right - will like create a compile error which is
 pretty confusing. Oh well.

 One thing I asked for some time ago was for the is_float to be defined in
 terms of numeric_limits - more or less as you have done here. At least
 that would keep things
 in one place. Actually it's not clear what the designers of numeric
 limits had in mind by not explicitly specifying is_float.

 Question: what does this mean for someone who synthesizes a floating point
 decimal? What will this code do? Also what about a fixed point decimal.
 I'm generally concerned about undefined behavior and unintended
 consequences when we are "too clever" as I'm thinking we might be here.

 Anyway, I gave credit to you in the comments for the fix.

 Robert Ramey

 I remember some special types - like int64 in microsoft failed to support
 stream << and >> operators. I don't know if that's still true.

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:14 UTC