Difference in digits10 between GCC and MSVC

I have the following code:

#include <iostream>
#include <limits>

int main()
{
   std::cout << std::numeric_limits<unsigned long long>::digits10 << std::endl;
   return 0;
}

• GCC 4.4 returns 19
• MS VS 9.0 returns 18

Can someone please explain Why is there a difference between the two? I would 开发者_运维百科have expected such a constant would be the same regardless of the compiler.

---

If Visual C++ 2008 returns 18 for std::numeric_limits<unsigned long long>::digits10, it is a bug (I don't have Visual C++ 2008 installed to verify the described behavior).

In Visual C++ (at least for 32-bit and 64-bit Windows), unsigned long long is a 64-bit unsigned integer type and is capable of representing all of the integers between zero and 18,446,744,073,709,551,615 (2⁶⁴ - 1).

Therefore, the correct value for digits10 here is 19 because an unsigned long long can represent 9,999,999,999,999,999,999 (19 digits) but cannot represent 99,999,999,999,999,999,999 (20 digits). That is, it can represent every 19 digit number but not every 20 digit number.

When compiled with Visual C++ 2010, your program prints the expected 19.

---

numeric_limits::digits10 specifies the number of decimal digits to the left of the decimal point that can be represented without a loss of precision. So, I guess it will differ from compiler to compiler depending on their implementation detail.

---

In general, the statement

I would have expected such a constant would be the same regardless of the compiler.

is not correct because the size of a type in C isn't fixed. The standard only mandates a minimum limit and compilers are free to use wider types. For example some weird compilers on a 32 or 64-bit computer may have CHAR_BIT = 9 and unsigned long long wouldn't be 64 bit any more, or it may use different 1's complement or some other number encodings. In short, the result may vary between compilers.

However in case that unsigned long long is a 64-bit type then it's definitely a bug. I've just checked and saw that the bug has been fixed in VS 2008. The correct value of 19 is returned