I agree with that statement. How can you use type when you don't know range of values. I want to store year. From 1850 to 2050. What type should I choose? I want to store colour value: from 0 to 2^24-1. What type should I choose?

How long does it take you to code a program if you are being bogged down by such simple problems? Use ints and do bounds checking when it's necessary to do so. Is every single bucket of information a reinvention of types?

int, long. The standard specifies their minimum sizes.

Or include cstdint and use the fast or least types as needed.

It specifies the minimum sizes, in the sense that sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) etc... but no requirements on how big they actually are. You could (in theory) end up with all of those being 9 bits wide on some weird platform.

No, they cannot all be 9 bits, they have higher minimums.

https://en.wikipedia.org/wiki/C_data_types#Basic_types

X86 has also had saturation arithmetic since MMX was introduced.

.... However, unless you use non portable intrinsics, you can't make the compiler use MMX. So in practice you get wrap on overflow.

Worse, the compiler is entitled to use saturation arithmetic if you've assumed wrapping.

> Worse, the compiler is entitled to use saturation arithmetic if you've assumed wrapping.

C89 (draft[1], because the actual spec is not public) section 3.1.2.5 states:

> ... a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer type.

So, unless I'm misunderstanding, the compiler is not entitled to use saturation arithmetic on unsigned integers.

[1] http://port70.net/~nsz/c/c89/c89-draft.html

signed and unsigned have different semantics.

The compiler is allowed to do literally anything on signed overflow, including launching the missiles, and not running the program. Or both.

You can build portable libraries on top of nonportable primitives.

You should never rely on the underlying CPU architecture's behavior on integer overflow when you write C or C++. It is undefined and not unspecified or implementation defined.

Undefined behaviour is undefined only by the standard - an implementation may choose to handle undefined behaviour in some documented, specific fashion. Undefined behaviour exists to give implementations exactly this flexibility.

> an implementation may choose to handle undefined behaviour in some documented, specific fashion

Or they can leave it undefined and not make any guarantees. I do not think that any compilers on any platform makes any guarantee on signed overflow.

true, but the behavior of unsigned integers is defined such that they can't overflow. the "wrapping" behavior of unsigned ints is defined: you get the arithmetic result modulo the max value for that width.

You can store year 1850-2050 in a byte.

I've been programming in C and C++ for almost 30 years. This has never been a problem for me.

> I agree with that statement. How can you use type when you don't know range of values.

That might be a question for developers of the billons of lines of C++ in production. Asking them, you'd discover how they they actually use the builtin types.

If you work with formal verification this is a pretty common sight.

If you work with smaller embedded systems and you need portability this is also a common sight (when you also quote the part about cstdint, which most embedded people will be happy with).

On a different platform, these "friendly" types can be larger, typically 2 or 4 times larger which can be devastating for performance, or smaller, leading to overflow. They are only "usable" if you restrict yourself on one version, of one compiler, on one hardware platform.

Since C++11 there are types like 'uint_fast32_t', which does allow for platform independent code.

Does C++ not have int32_t and the like from C?

It does. I personally stick to those exclusively except for for loop index variables.

What would be different about loop variables? I don't really write C++.

I'm assuming here that they would use the `size_type` for the container they are iterating over. Otherwise I'm not sure.

An unsigned type is sometimes a poor choice for a loop index. The compiler then cannot assume the loop will terminate, and generate worse code. Usually this doesn't matter -- until you discover it did.

Good point. Probably not a problem in practice for most containers, but yet another reason for why the STL (and C library, for that matter) should have used a signed size type from the beginning.

Yep, it's to match vector/array size_type and difference_type, although I tend to just use size_t and ptrdiff_t directly.

It's a good choice. Sometimes your best choice for a general purpose int is

    typedef Int int32_t;

for the entire compilation as a whole, and when things get screwy just bump Int up to int64_t and take the performance hit for the extra bit of safety

"i32" is better.

Yes

You can still use the Uint32/Uint8/... types. While performance can vary from system to system, the range should be the same on all reasonable platforms.

Or “mostly” ;)

const std::string unusable = "unsuitable";