On Tuesday, 15 October 2019 09:34:09 PDT Andrey Semashev via Std-Proposals
wrote:
> The same thing is with integers. The standard doesn't say much about
> int, so you can't be confident about which integer values are
> representable by int and which are not. This is especially sad, given
> that signed overflow is UB. So, basically anything beyond a toy project
> should use intN_t in order to have behavior that can be reasoned about,
> especially in corner cases.

The standard does give minimum maximum values for short, int and long, so you
can be assured they are at least that big. You also know the relationship
between them, so you know you can promote without loss if you go up the
ladder.

Also, don't forget uinptr_t, size_t and ptrdiff_t. You *really* shouldn't use
a specific bit count when dealing with object sizes and pointers.

That means you don't need uint32_t for counting the elements in an array that
you declared in your function. int, size_t or ptrdiff_t would be just fine.

I firmly believe you should use types that are good enough for your needs, not
coerce them to specific sizes. Back in the 1990s, when I started coding,
float, double and long double had the same performance due to the i387 FPU
always operating in 80-bit extended precision. So I wrote all my code with
long doubles. But after 2004, long doubles are MUCH slower than floats and
doubles. Even today, some operations (like division) are faster on floats than
on doubles.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products