Why is an integer always used as the controlling variable in a for loop?_问答_开发者

There are often times when you know for a fact that your loop will never run more than x number of times where x can be represented by byte or a short, basically a datatype smaller than int.

Why do we use int which takes up 32 bits (with most languages) when something like a byte would suffice which is only 8 bits.

I know we have 32 bit and 64 bit processes so we can easily fetch the value in a single trip but it stil开发者_如何学编程l does consume more memory. Or what am I missing here?

UPDATE: Just to clarify. I am aware that speed wise there is no difference. I am asking about the impact on memory consumption.

In C, an "int" is defined as the most efficient integer type for the current machine.

It usually match the registers of the CPU, that's how it is the most eficient.

Using a smaller type of integer value may result in some bit-shifting or bit masking at the CPU level so you would get no gain...

Accessing an integer size that is the same size as the native word size is going to be the most efficient. Using a byte will almost certainly require as much space as the native word size and require shifting and masking to access, so there is nothing to gain.

In practical terms, unless you have a very, very large loop or severe timing restrictions, it isn't going to make much difference.

But as always, use whatever is most readable, and benchmark/profile first...

I almost always use int unless there is a very good reason not to, just because everyone always uses it. This is to avoid the next developer having to spend time thinking Why didn't he use an int here, is there some special reason I need to know about.

The more standard my code is, the easier it is to read in the future.

In many cases, the loop counter consumes exactly one processor register. Changing the type to an 8- or 16-bit integer doesn't change that, as the registers have fixed size (32 bits on a 32-bit platform, etc.).

Sometimes, the loop counter may be placed in RAM, e.g. when you are calling a function from the loop. Then, yes, you may be wasting a few bytes, but generally not enough to be worried about. Storing and loading the loop counter may in fact be slower when using something different from an int.

In terms of the Java Language Specification there is an interesting point to note about the use of long and double:

For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64 bit value from one write, and the second 32 bits from another write. Writes and reads of volatile long and double values are always atomic. Writes to and reads of references are always atomic, regardless of whether they are implemented as 32 or 64 bit values. VM implementors are encouraged to avoid splitting their 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications.

Clearly this makes using a long or double in your looping variable less efficient than an int in the Java memory model, but implementations may vary in performance.

I'm tempted to add something here even if it's a very old thread. I don't fully agree with "I am aware that speed wise there is no difference". Indeed, very often in for loop there is array indexing such as in

for (i=0; i<len; i++) s = A[i]

Then, even if your array is of size less that 128, you will see a notable speed difference whether i is an int or a byte. Indeed, to perform pointer arithmetic in A[i] the processor has to convert your integer into something which has the same size as a pointer. If the integer already has the same size, then there is no conversion which induce faster code. On a 64 bits machine, I've seem 20% speedup on programs by using long int for loop indexes on very small array instead of char (C/C++ programs).