With the pervasiveness of 64-bit architectures, it's more important than ever that your Linux software be 64-bit ready. Learn how to avoid portability pitfalls when making declarations and assignments, bit shifting, typing, formatting strings, and more.
To read all comments associated with this story, please click here.
Member since:2005-12-31
> Programmers should choose the max int size supported by the CPU for most things.
No, programmers should always choose the smallest possible int size for the task at hand. For example, to store a number between 0 and 20000, use a 16-bit int (<15 bits cannot store all possible values; 15 bits cannot be handled by the platform; 16 bits are ok). Exception: Some CPUs, when computing their native size, are faster than with smaller sizes - in that case use the native size.
If the range of possible values is unknown at design time - tough luck, use a variable-sized integer. Too many programmers use a fixed-size integer that is "big enough" because they are too lazy or too uninformed, and because they were not the ones how blew up the Ariane 5 with exactly such a mistake.
Member since:2006-03-13
I forsee a CPU which has a 64-bit stack and a RISC instruction set which handles ints and floats like the FPU. It's native will be 64-bit. I don't see sizes larger than 64-bit emmerging. 64-bit is the end of the line. I've written an operating system and compiler with this in mind--LoseThos. (http://www.justrighteous.org) Picking-and-choosing sizes just leads to errors. Obviously, when many instances of a variable are present--arrays, you pick the appropriate size.
Member since:
2006-03-13
Programmers should choose the max int size supported by the CPU for most things. For data in structures and arrays, they should choose a smaller size.