Re: [Boost-bugs] [Boost C++ Libraries] #10639: lexical_cast<double>(string) wrong in C++11

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #10639: lexical_cast<double>(string) wrong in C++11
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-10-11 12:10:15

#10639: lexical_cast<double>(string) wrong in C++11
--------------------------------+--------------------------
  Reporter:  richard.kreckel@…  |      Owner:  apolukhin
      Type:  Bugs               |     Status:  assigned
 Milestone:  To Be Determined   |  Component:  lexical_cast
   Version:  Boost 1.56.0       |   Severity:  Problem
Resolution:                     |   Keywords:
--------------------------------+--------------------------

Comment (by apolukhin):

 Replying to [comment:3 johnmaddock]:
 > Given:
 >
 > {{{
 > const wide_result_t result = std::pow(static_cast<wide_result_t>(10.0),
 pow_of_10) * mantissa;
 > }}}
 >
 > Then you have two floating point operations - which is to say, even if
 std::pow is accurate to 0.5ulp, and the multiplication likewise, you can
 still be wrong to 1ulp in the final result.  Note that this is true even
 if long double is wider than double due to the "double rounding" problem:
 http://www.exploringbinary.com/double-rounding-errors-in-floating-point-

 conversions/.

 Seems like a final nail into the coffin of my naive implementation. That's
 sad, std::num_get and others work slow because of memory allocations or do
 not respect locale specific separators. I'll force lexical cast to use
 std::stream based conversions, but this change possibly won't get its way
 into the 1.57 release (significant change that requires more testing).

 > You are correct that your code is the same in C++03 and C++11 modes
 which makes me wonder what's changed - my guess is that because of the
 issues outlined above, your code will be very susceptible to choice of
 floating-point registers used, and/or the level of compiler optimization
 used.  Which is to say, the compiler only has to output slightly different
 code at the machine level, and stuff which worked before - largely by
 accident - will now break.

 There's almost no chance that two compilers maintained by two different
 teams will change code generation between two minor releases at the same
 time only for the same specific set of input options.

 This looks more like a regression in Standard Library implementation. As I
 understand in both test cases (Clang and GCC) the same Standard Library
 was used which makes it the first candidate for inspection.

 > Fun isn't it? ;-)

 It makes me think that libc++ developers never stop laughing because of
 such fun... :-)

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/10639#comment:4>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.