C++ Precision: String to Double

I am having a problem with precision of a double after performing some operations on a converted string to double.

#include <iostream>   
#include <sstream>
#include <math.h>

using namespace std;

// conversion function
void convert(const char * a, const int i, double &out)
{

   double val;

   istringstream in(a);
   in >> val;

   cout << "char a -- " << a << endl;
   cout << "val ----- " << val << endl;

   val *= i;

   cout << "modified val --- " << val << endl;
   cout << "FMOD ----- " << fmod(val, 1) << endl;

   out = val;

   return 0;

}

This isn't the case for all numbers entered as a string, so the error isn't constant. It only affects some numbers (34.38 seems to be co开发者_如何学运维nstant).

At the minute, it returns this when i pass in a = 34.38 and i=100:

char a -- 34.38
Val ----- 34.38
modified val --- 3438
FMOD ----- 4.54747e-13

This will work if I change the Val to a float, as there is lower precision, but I need a double.

This also is repro when i use atof, sscanf and strtod instead of sstream.

In C++, what is the best way to correctly convert a string to a double, and actually return an accurate value?

Thanks.

---

This is almost an exact duplicate of so many questions here - basically there is no exact representation of 34.38 in binary floating point, so your 34 + 19/50 is represented as a 34 + k/n where n is a power of two, and there is no exact power of two which has 50 as a factor, so there is no exact value of k possible.

If you set the output precision, you can see that the best double representation is not exact:

cout << fixed << setprecision ( 20 );

gives

char a -- 34.38
val ----- 34.38000000000000255795
modified val --- 3438.00000000000045474735
FMOD ----- 0.00000000000045474735

So in answer to your question, you are already using the best way to convert a string to a double (though boost lexical cast wraps up your two or three lines into one line, so might save you writing your own function). The result is due to the representation used by doubles, and would apply to any finite representation based on binary floating point.

With floats, the multiplication happens to be rounded down rather than up, so you happen to get an exact result. This is not behaviour you can depend on.

---

The "problem" here is simply that 34.38 cannot be exactly represented in double-precision floating point. You should read this article which describes why it's impossible to represent decimal values exactly in floating point.

If you were to examine "34.38 * 100" in hex (as per "format hex" in MATLAB for example), you'd see:

40aadc0000000001

Notice the final digit.