But while trying to store a 64-bit integer in double the exact value can be lost (see picture 1).I've seen that first hand. In fact, I wrote code to fix it. The guy who wrote the code, still did not get it... 64 bits is 64 bits he said, right... well yes, but that's not the issue here. When you have an int that is say 56 bits in size and you put it in a double that is 64 bits... see what happens:
#include <iostream>
#include <boost/integer.hpp>
int main()
{
boost::uint64_t too_big = 72057594037927936;
double wont_fit = too_big;
std::cout << too_big << "\n";
std::cout << wont_fit << "\n";
return 0;
}
./a.out
72057594037927936
7.20576e+16
The maddening part about this is that it's hit or miss. Smaller numbers fit just fine:
#include <iostream>
#include <boost/integer.hpp>
int main()
{
boost::uint64_t not_too_big = 281234;
double will_fit = not_too_big;
std::cout << not_too_big << "\n";
std::cout << will_fit << "\n";
return 0;
}
./a.out
281234
281234
Finding and fixing bugs like this will cause ulcers.
I've seen that first hand. In fact, I wrote code to fix it. The guy who wrote the code, still did not get it... 64 bits is 64 bits he said, right... well yes, but that's not the issue here. When you have an int that is say 56 bits in size and you put it in a double that is 64 bits... see what happens:
#include <iostream>
#include <boost/integer.hpp>
int main()
{
}./a.out
72057594037927936
7.20576e+16
The maddening part about this is that it's hit or miss. Smaller numbers fit just fine:
#include <iostream>
#include <boost/integer.hpp>
int main()
{
}./a.out
281234
281234
Finding and fixing bugs like this will cause ulcers.