There are two main problems with the shown code:
- The shown code attempts to build a binary version of the input number in decimal producing, for example, the result of
111
for the number 7. That's an integer value of one hundred and eleven.
On a 32 bit platform, with a 32 bit integer means that the largest number that can be "converted" to decimal this way will be 2047. 2048 is 10000000000 in binary, which will exceed the capacity of a 32 bit integer. An unsigned 32 bit integer's maximum value is 4294967295 (and half of that for it's plain, signed, int
value, but either signed or unsigned, you're out of gas at this point).
- Any use of
pow()
with two values that are integets is automatically broken by default, becase floating point math is broken. This is not what pow()
really does. Here's what pow()
does: a) it takes the natural logarithm of its first parameter, b) multiples the result from step a by its 2nd parameter, c) raises e
to the power resulting from step b. Does this sound like something you expected to do here?
And since pow()
takes floating point parameters, and the result is a floating point, the end result of the shown code is a bunch of needless conversions between floating point and integer values, and non-specific rounding errors as a result of imprecise floating point exponential math.
But the main flaw in the shown code is an attempt to use plain int
s to assemble a decimal number represented of a binary value, which simply doesn't have enough digits for this. Switching to long long int
won't be much of a help. Counting things off on my fingers, you'll be able to go up only to somewhere slightly north of a million, that way. A completely different approach must be taken for the described programming tasks.