int is a type that's at least 16 bits large. I can't see the problem with using it. If I specify that I want a type that's 32 bits large, my code won't run on 16 bit systems.
Why should I assume? Because the author doesn't believe in writing code that works on "20 year old systems"?
That said, there's really no way to correctly pick the "perfect" integer size for every platform - There's just too many variables. IMO I much prefer to just use 'int' when I know the values are going to be small - smaller then a 16-bit value - and I don't care about the actual width. But obviously it's a hot topic for some - As long as you follow the standard in regards to it's size then it doesn't really matter what integer value you choose to use. I prefer saving the fixed-width integer types for situations when I know I need such a size.
If the loop variable is a int_fast16_t the loop increment step compiles to
addq $1, -16(%rbp)
movzwl -4(%rbp), %eax
addl $1, %eax
movw %ax, -4(%rbp)
Without profiling there's no way to tell on modern processors.
Comparatively, while one is three instructions and the other is one, that single instruction is still doing everything the other three are doing. The only reason they aren't both one instruction seems to be that `addw` must not being a thing (Why, I don't know). Since the I/O done by both will be nearly identical, and the addition's should be very comparable in speed, it's not crazy to say they should perform basically the same. If you compiled with -O2 I bet you'd see almost identical code, since it would probably remove the memory access.
Yes, the int is technically less portable. No, I don't see any reason to use that longer name.
Why not?
I've read that if one uses int64_t with a compiler that targets a 32 bit system, doing various operations on the int64_t variable will be much slower because more machine code instructions need to be generated.
The point stands: Why not use int if one is looking to target any architecture that C will run on?
In most places, if you're using an `int` for non-address-y stuff you're just wasting space on wider archs, or you're overflowing on less wide ones. The only exception off the top of my head is "I have an array of bytes, but want to bulk process more efficiently than u8 would allow". Things like `size_t` (or explicit SIMD types!) are still probably a better choice there, if only to simplify the rule to "just don't use int".
This will often generate more code. So don't do this except when it saves a modest amount of memory.
Yep, but presumably you picked int64_t for a reason. If you want a 32-bit variable, use int32_t.
It would be an extremely rare platform on which int16_t is noticeably slower than int. The very minor platform-specific performance improvement you might get from using int rather than int16_t is very rarely worth the risk of introducing an overflow on the few platforms where int is 16 bits[1], and not noticing it because int is longer than that on the platform you develop on.
[1] remember that a signed integer overflow is undefined behaviour which should be regarded as equivalent to a security flaw - the compiler is permitted to send all data your program has access to to the mafia if your program contains a signed integer overflow anywhere, and some compilers will
If they used 'int_fast16_t' from <stdint.h>, you have at least an idea that they considered that it might only be 16 bits, and that it can be a larger type on systems where operations on 64-bit types are faster.
`int` is at least 16 bits, `long` is at least 32 bits, `long long` is at least 64 bits, and `size_t` is big enough to hold the size of the largest object you can allocate - and in most cases that is all you need to know.
The exact width types can be useful if you're marshalling data to and from an exact-width format, like a network protocol or file format.
You should know the range of values that you are expecting to be holding in an integer, and choose the type accordingly.
The only advantage to choosing an exactly-N-bit type over an at-least-N-bit type is possibly saving some space in very large allocations. In most cases this won't be important - and when it is, the mininmum-width types from stdint.h (eg int_least32_t) are more apropos than the exact-width types.
The disadvantage is the impedance mis-match with all the existing libraries of code using the basic types.
IMHO, "int" is perfectly acceptable if you just want to use the platform's preferred word size (and are fine with the possibility of it being only 16bit). Also, "char" is perfectly acceptable too if you're dealing with ASCII. This is valid for both the signed and unsigned variants.
The general rule should be using the language types as long as you're not assuming something about their size, only then use "stdint.h" because it makes your assumption more explicit.
Now, nobody uses "short" or "long" to mean "something smaller or shorter than the platform's int", so these are usually something to avoid.
Same goes for unsigned versions and long long.
Granted, divisions are rare, but that's still nearly an order of magnitude difference in that corner case.
32-bit and 64-bit addition, multiplication, comparison, logical operations etc. are in almost all cases just as fast.
You'll still need more storage on the stack for 64-bit variables. So more cache misses (and perhaps TLB misses and page faults) when corresponding boundary is crossed.