11

Uses and when to use int16_t, int32_t, int64_t and respectively short, int, long.
There are too many damn types in C++. For integers when is it correct to use one over the other?

shovel_boss
  • 129
  • 1
  • 1
  • 5
  • 7
    Stick with the undamned ones. – Scott Hunter Aug 10 '16 at 01:02
  • 6
    ...and the undamned zeros. – Captain Obvlious Aug 10 '16 at 01:03
  • Context for such a generic question would be nice. Type and typesize handling carries different amounts of weight depending on what platforms and lifetime you need to support. If you have locked strides in bits on an embedded you have very different needs than someone writing OOP stuff for .NET. C++ has so many damn types because it support so many damn vastly different platforms. –  Aug 10 '16 at 01:59

5 Answers5

8

Use the well-defined types when the precision is important. Use the less-determinate ones when it is not. It's never wrong to use the more precise ones. It sometimes leads to bugs when you use the flexible ones.

Blair Houghton
  • 467
  • 3
  • 10
  • 4
    It's wrong to use the "more precise" ones when they don't exist. – Pete Becker Aug 10 '16 at 01:43
  • 2
    caveat emptor: platform specificity matters. Make sure you use types supported across all your targets, which depending on your implementation can mean using a generic one that behaves well across the deployment matrix, or micro managing specific ones and providing consistency yourself –  Aug 10 '16 at 02:04
  • 1
    @PeteBecker As a last ditch effort to use the "more precise" ones, you could define them for the platform you are working, when porting from a platform that did have them to one that does not. – DarthRubik Aug 12 '16 at 22:31
5

Use the exact-width types when you actually need an exact width. For example, int32_t is guaranteed to be exactly 32 bits wide, with no padding bits, and with a two's-complement representation. If you need all those requirements (perhaps because they're imposed by an external data format), use int32_t. Likewise for the other [u]intN_t types.

If you merely need a signed integer type of at least 32 bits, use int_least32_t or int_fast32_t, depending on whether you want to optimize for size or speed. (They're likely to be the same type.)

Use the predefined types short, int, long, et al when they're good enough for your purposes and you don't want to use the longer names. short and int are both guaranteed to be at least 16 bits, long at least 32 bits, and long long at least 64 bits. int is normally the "natural" integer type suggested by the system's architecture; you can think of it as int_fast16_t, and long as int_fast32_t, though they're not guaranteed to be the same.

I haven't given firm criteria for using the built-in vs. the [u]int_leastN_t and [u]int_fastN_t types because, frankly, there are no such criteria. If the choice isn't imposed by the API you're using or by your organization's coding standard, it's really a matter of personal taste. Just try to be consistent.

Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
3

This is a good question, but hard to answer.
In one line: It depends to context:

My rule of thumb:

  • I'd prefer code performance (speed: less time, then less complexity)
  • When using existing library I'd follow the library coding style (context).
  • When coding in a team I'd follow the team coding style (context).
  • When coding new things I'd use int16_t,int32_t,int64_t,.. when ever possible.

Explanation:

using int (int is system word size) in some context give you performance, but in some other context not.

I'd use uint64_t over unsigned long long because it is concise, but when ever possible.

So It depends to context

0

A use that I have found for them is when I am bitpacking data for, say, an image compressor. Using these types that precisely specify the number of bytes can save a lot of headache, since the C++ standard does not explicitly define the number of bytes in its types, only the MIN and MAX ranges.

deadbird11
  • 147
  • 2
  • 8
0

In MISRA-C 2004 and MISRA-C++ 2008 guidelines, the advisory is to prefer specific-length typedefs:

typedefs that indicate size and signedness should be used in place of the basic numerical types. [...]

This rule helps to clarify the size of the storage, but does not guarantee portability because of the asymmetric behaviour of integral promotion. [...]

Exception is for char type :

The plain char type shall be used only for the storage and use of character values.

However, keep in mind that the MISRA guidelines are for critical systems.

Personally, I follow these guidelines for embedded systems, not for computer applications where I simply use an int when I want an integer, letting the compiler optimize as it wants.

AdriZ
  • 393
  • 3
  • 9