Can't hold numbers in variable.

This is a discussion on Can't hold numbers in variable. within the C Programming forums, part of the General Programming Boards category; Hey all,
I am using a bar code scanner to scan a number into my program. A typical bar code ...

Can't hold numbers in variable.

Hey all,

I am using a bar code scanner to scan a number into my program. A typical bar code number is somewhere around 12 digits long. I have to use a float for this because its too big for an integer. That works... but the only problem is that it also gives me a slew as 0000000's at the end. How can I allleviate this problem?

Change %f to %.0f in your printf() call. Also, you might want to consider using a string instead of an integer to hold the data. Or use a larger integer type. If you #include <stdint.h> you should be able to declare a uint64_t type which creates an unsigned 64-bit integer that can easily hold a 12-digit number.

Longs are typically 32-bit nowadays on Windows-type machines. 32-bit integers can only handle up to 9 digits (10 digits if the first digit is less than 4). I'd strongly recommend using a string to hold the number instead. But if the data absolutely has to be in numeric format then it should be in a 64-bit integer instead of a float.

Strings would be a good bet. I'm always hearing debates about 64-bit integers and processing speeds and stuff. I don't really know the details, but you got a few good programmers saying they're alright, so you can do either or I guess.

64-bit would be ok if you had a 64-bit CPU. However since XP is currently not 64-bit on a 32-bit system and in fact cannot be pure 64-bit - using 64 bits will incur a speed hit. Remember the days when all we had was 16 bits? Say for instance we had a large value and needed to store it? You would use AX and another register to represent the value. Then you would use an algo to combine the values into a final result to be displayed. For an explanation of this algo I recommend reading The Art of Assembly Language by Randall Hyde. The same process must be used to use a 64-bit value on a 32-bit CPU. Now I'm sure that most, if not all, CPUs by now are internally 64-bit but as of yet Intel has not exposed any standard 64-bit registers external to the CPU, excluding MMX(x) and SSE(x).

So a 64-bit value must be stored in two 32-bit registers to be used by the CPU. You also cannot load a 64-bit value from memory into the CPU even in MMX. In fact MMX specifically prohibits this and so to me it's functionality and usefuleness in certain situations is quite limited. You can store a 64-bit value into memory by a combination of opcodes but again this requires cycles. Probably won't notice the difference given the insane clock speeds we have today but the underlying mechanism is using two 32-bit values to represent one 64-bit value.

Using the floating point processor solely for the purpose of gaining digits is not recommended by Intel. Their are a lot of problems with this approach. The FPU is intended to be used with floating point values only and not integral values. The floating point architecture is designed to operate efficiently on floats and the CPU will operate efficiently on integral values. Using an FPU to simply gain digits might cause the underlying assembly code to leave the FPU in an unpredictable state. There is a lot more going on in the FPU opcodes that you might think and it operates on a totally different principle. Check the Intel documentation concerning the math-coprocessor functions and operations. You will be quite surprised by what you find. You may also want to check your compiler documentation to see if and when it issues a reset to the FPU. The FPU state and registers must be reset under certain conditions to ensure accuracy and proper calculation of values. If this state become invalid then all data output from the FPU will also be invalid. Several combinations of opcodes and/or operations whether they be in C/C++ or in pure asm can and will leave the FPU in an invalid state. It is also possible with your setup that you might encounter a NaN which is essentially a not a number flag. There are values for which no known binary representation exists in the FPU format. Compensations for this will result in a loss of precision and could alter your final value even though you did not intend for it to do this.

So, in short, use a string. It is more suited to what you want to do. Use the FPU correctly and your code will get along quite nicely with it.