When to use `short` over `int`?

Question

There are many questions that asks for difference between the short and int integer types in C++, but practically, when do you choose short over int?

Solution 1

(See Eric's answer for more detailed explanation)

Notes:

• Generally, int is set to the 'natural size' - the integer form that the hardware handles most efficiently
• When using short in an array or in arithmetic operations, the short integer is converted into int, and so this can introduce a hit on the speed in processing short integers
• Using short can conserve memory if it is narrower than int, which can be important when using a large array
• Your program will use more memory in a 32-bit int system compared to a 16-bit int system

Conclusion:

• Use int unless you conserving memory is critical, or your program uses a lot of memory (e.g. many arrays). In that case, use short.

Solution 2

You choose short over int when:

Either

• You want to decrease the memory footprint of the values you're storing (for instance, if you're targeting a low-memory platform),
• You want to increase performance by increasing either the number of values that can be packed into a single memory page (reducing page faults when accessing your values) and/or in the memory caches (reducing cache misses when accessing values), and profiling has revealed that there are performance gains to be had here,
• Or you are sending data over a network or storing it to disk, and want to decrease your footprint (to take up less disk space or network bandwidth). Although for these cases, you should prefer types which specify exactly the size in bits rather than int or short, which can vary based on platform (as you want a platform with a 32-bit short to be able to read a file written on a platform with a 16-bit short). Good candidates are the types defined in stdint.h.

And:

• You have a numeric value which does not need to take on any values that can't be stored in a short on your target platform (for a 16-bit short, this is -32768-32767, or 0-65535 for a 16-bit unsigned short).
• Your target platform (or one of you r target platforms) uses less memory for a short than for an int. The standard only guarantees that short is not larger than int, so implementations are allowed to have the same size for a short and for an int.

Note:

chars can also be used as arithmetic types. An answer to "When should I use char instead of short or int?" would read very similarly to this one, but with different numbers (-128-127 for an 8-bit char, 0-255 for an 8-bit unsigned char)

In reality, you likely don't actually want to use the short type specifically. If you want an integer of specific size, there are types defined in <cstdint> that should be preferred, as, for example, an int16_t will be 16 bits on every system, whereas you cannot guarantee the size of a short will be the same across all targets your code will be compiled for.

Solution 3

In general, you don't prefer short over int.

The int type is the processor's native word size
Usually, an int is the processor's word size.

For example, with a 32-bit word size processor, an int would be 32 bits. The processor is most efficient using 32-bits. Assuming that short is 16-bit, the processor still fetches 32-bits from memory. So no efficiency here; actually it's longer because the processor may have to shift the bits to be placed in the correct position in a 32-bit word.

Choosing a smaller data type There are standardized data types that are bit specific in length, such as uint16_t. These are preferred to the ambiguous types of char, short, and int. These width specific data types are usually used for accessing hardware, or compressing space (such as message protocols).

Choosing a smaller range
The short data type is based on range not bit width. On a 32-bit system, both short and int may have the same 32-bit length.

Once reason for using short is because the value will never go past a given range. This is usually a fallacy because programs will change and the data type could overflow.

Summary
Presently, I do not use short anymore. I use uint16_t when I access 16-bit hardware devices. I use unsigned int for quantities, including loop indices. I use uint8_t, uint16_t and uint32_t when size matters for data storage. The short data type is ambiguous for data storage, since it is a minimum. With the advent of stdint header files, there is no longer any need for short.

Comments

[clcto]

Note: There is no guarantee that a short actually uses less memory than an int, it is implementation defined.

[gexicide]

Zero/Sign extending is not that expensive. I would not mind the performance hit too much. Once you store a lot of numbers, choose the type with the tightest fit to save memory and thus also increase cache locality. The reduced number of cache misses will usually be more important than the cost of extending from short to int.

[Admin]

If memory use is critical, then I break out the counting arguments and search for a reasonable bound on the values, and then I use the smallest integer type that encompasses that. Using short from some vague notion of it being smaller is both risky (it may be too small) and unreliable (it may be not be as small as you can go). When you care enough about memory use to deviate from int, I'd just use [u]intX_t for some appropriate X.

[TemplateRex]

@delnan Re "reasonable bound": beware of the [keyhole problem](se.ethz.ch/~meyer/publications/OTHERS/scott_meyers/‌​keyhole.pdf) from introducing gratuitous restrictions.

[Admin]

@TemplateRex Yes, a very real problem, but even worse when you arbitrarily pick a short (or long or char or whatever), mostly because you didn't even consciously set a restriction that's somewhat grounded in reality (or the back-of-the-envelope version of reality), you just "saved" an unknown amount of memory by introducing a platform-dependent, arbitrary restriction based on a gut feeling.

[BernieP]

Keeping in mind all considerations listed above, you might also want to consider it to decrease your disk footprint if writing a lot of data to disk.

[Eric Finn]

@user1074069 Good idea. I've added that (as well as mentioning sending data over the network) and mentioned that you should use fixed width integer types rather than types whose width can vary by platform.

[Thomas Matthews]

There is no guarantee that access a memory page as short (16-bit) is faster than int (32-bit). For example, if you want a 16-bit quantity from memory and the processor word size is 32, the processor may have to shift the bits left or right to place them in the correct position.

[Thomas Matthews]

Also, accessing 2 16-bit quantities from memory may be faster using a 32-bit fetch. Depends on the Memory Management Unit.

[Eric Finn]

@ThomasMatthews I was trying to get across that accessing 2048 16-bit values is likely faster than accessing 2048 32-bit values, as the former fits in 1 memory page (assuming 4 KB pages), while the latter takes 2 memory pages. Is there another way to word my answer to make that more clear? Or are you saying that my assumption there is invalid?

[Thomas Matthews]

@EricFinn: In a 32-bit system, accessing 2048 16-bit values is faster accessed as 1024 32-bit values. Many compilers will often emit code to access even quantities of 16-bit values using 32-bit fetches (2 values with 1 fetch is very efficient).

[Thomas Matthews]

@EricFinn: Also remember that a 32-bit data type also satisfies the range conditions for a short. With some compilers and platforms, short is the same as int, which means when you want 16-bits, you're getting 32. See uint16_t and uint32_t data types in stdint.h.

[Måns Thörnvik]

Excellent explanation!

[Big Temp]

How about a word in amd64? On my platform it's 32-bit, which is neither the 16-bit x86 assembly 'word' nor the actual native word size of a 64-bit processor.