Thread: numeric header - number of digits

I'm trying to create a buffer to be filled by sprintf() in order to convert an unsigned long to a string:

From the documentation, I'm having trouble deciding if this is the correct size for the buffer:

Code:

char buff[numeric_limits<unsigned long>::digits + 1];

Did I understand digits correctly?

>Did I understand digits correctly?
Yes and no. In this case, you missed that digits relies on radix, which is 2 for the basic integer types.

Since you seem to want the decimal digits, you should be using digits10 instead of digits. However, this is a tricky area because digits and digits10 both say that they evaluate to the number of digits representable by the type "without change". In the case of digits10, you'll be getting the number of digits - 1 because the most significant digit is a troublemaker. Let's say that unsigned long is 32 bits. The largest value that can be held by a 32-bit unsigned type on your system is probably 4,294,967,295. That's ten digits. However, digits10 can't evaluate to 10 because that doesn't guarantee the value will be representable by an unsigned long (9,999,999,999 for example). So digits10 will evaluate to 9. That also doesn't take sign or other formatting characters into account. At the very least, your array will need to use digits10 and add 3: 1 for the null character, 1 for the most significant digit, and 1 for the sign.

Very informative, Prelude. Thanks.

But to make sure I understood, digits10 will evaluate to the maximum possible number of decimal digits without incurring in the error of being representable by a number higher than max()?

Also, being this an unsigned long, is it still necessary to take into account the sign?

>digits10 will evaluate to the maximum possible number of decimal digits
>without incurring in the error of being representable by a number higher than max()?
That works.

>Also, being this an unsigned long, is it still necessary to take into account the sign?
Standard formatted output will ignore the sign for unsigned types (fancy that). However, application formatting might not see it in the same light and you would need the extra space. I like to err on the side of caution.

Most excellent! Thanks