C++ type system AKA what is exactly int ?

[Sesse]

No, it is guaranteed to be the size of unsigned char, which is the smallest possible type in C++ (sizeof(byte) == 1).

Well, to be accurate, the smallest possible addressable type. You can have bitfields that are smaller.

[Dann Corbit]

While minimum size is guaranteed, int, long and long long are not defined as to a maximum size.

If you need an exact size of bits, there are special types guaranteed by C++ 11:
https://en.cppreference.com/w/cpp/types/integer
For instance, int_fast64_t is guaranteed to be a fast 64 bit integer type.

[Bo Persson]

While minimum size is guaranteed, int, long and long long are not defined as to a maximum size.

If you need an exact size of bits, there are special types guaranteed by C++ 11:
https://en.cppreference.com/w/cpp/types/integer
For instance, int_fast64_t is guaranteed to be a fast 64 bit integer type.

It still says "at least" 64 bits, not exactly 64 bits. And the implementations does not have to document its definition of "fast". Particularly it doesn't say "fastest type for chess programs".

The only exact size types are int64_t et al, with the provision "if available". And when available, I bet it has excatly the same properties as "long long".

[Dann Corbit]

I suppose that is true enough.
Consider a hypothetical case though, of a machine with 128 bit native register size.
Addressing, shifting, etc may be fastest with these.
So using a 64 bit integer might be slower.

No worry today, because we do not have 128 bit architectures yet (except in extensions like SSEx, etc) so it probably won't matter for a few years.

[Sesse]

It is unlikely we'll be seeing 128-bit CPUs. Traditionally, the shift to wider architectures have been due to the need to address more RAM, not do arithmetic on bigger values, and 2 EB of RAM seems to be enough for a while… (Typically address space in current 64-bit CPUs is not even full 64-bit.)

It's also fairly likely that a theoretical 128-bit CPU would be able to do efficient arithmetic on 64-bit values, similar to how a modern 64-bit CPU deals with uint32_t just fine (through implicit zero extension, or the slightly slower sign extension in some cases).

[Dann Corbit]

I think the shift to 128 bits will be driven by:
1. Need for fast arithmetic.
Cryptography
Graphics
2. File systems

[JohnWoe]

Every time I write int/float/char I wonder what the hell they actually are.

Is int 32b/64b?
Actually int can be infinite bits as well char.
This is missing from Rust.

So should I write int32_t instead?

If I remember correctly, "int" is defined is either 2 or 4 bytes, depending on the default as set by the architecture.

Rust does not have "int". It uses uX / iX (unsigned / signed, where X is 8, 16, 32, 64 or 128 bits), or usize / isize (signed / unsigned, where "size" means "go as high as you can go on the architecture you're compiling on").

The size of this primitive is how many bytes it takes to reference any location in memory. For example, on a 32 bit target, this is 4 bytes and on a 64 bit target, this is 8 bytes.

So, I assume if Rust was available for 16 or 128 bit systems, usize would be 16 or 128 bits on those systems.

I meant this confusion is missing from Rust. Rust has very simple type system w/ u8 / i32 / u8 / str.

In C++ we write int / long instead of uint32_t / uint64_t ... Because the compiler will somehow magically generate faster binary. That's a serious design flaw

Actually I only use int in C++ nowadays.

---

33 bit int? I don't care as long as it's fast. I just want to avoid UB and wrap.

I played with godbolt a little bit with these types. int was .long = 4 bytes, char .byte = 1 byte. Nothing new here. Clang created the best assembly out of icc/gcc/msyc.

[Bo Persson]

Every time I write int/float/char I wonder what the hell they actually are.

Is int 32b/64b?
Actually int can be infinite bits as well char.
This is missing from Rust.

So should I write int32_t instead?

If I remember correctly, "int" is defined is either 2 or 4 bytes, depending on the default as set by the architecture.

Rust does not have "int". It uses uX / iX (unsigned / signed, where X is 8, 16, 32, 64 or 128 bits), or usize / isize (signed / unsigned, where "size" means "go as high as you can go on the architecture you're compiling on").

The size of this primitive is how many bytes it takes to reference any location in memory. For example, on a 32 bit target, this is 4 bytes and on a 64 bit target, this is 8 bytes.

So, I assume if Rust was available for 16 or 128 bit systems, usize would be 16 or 128 bits on those systems.

I meant this confusion is missing from Rust. Rust has very simple type system w/ u8 / i32 / u8 / str.

It is smpler, because it *is* a simplificication. But it also limits Rust to systems where an i32 is available. C and C++ didn't want to limit itself that way.

And at least C has been used with 24, 36, and 48 bit ints.

In C++ we write int / long instead of uint32_t / uint64_t ... Because the compiler will somehow magically generate faster binary. That's a serious design flaw

No, it is not faster when they are the same type.

The use of int32_t is that you get exactly 32 bits, when available. And nothing otherwise. It surely is a typedef for either int or long. Or a compile error when none of these have 32 bits.

You have to ask yourself where the exact size is important - in a network package, yes - in a loop counter, not so much.

So a bit more flexible, rather than a serious flaw.

Actually I only use int in C++ nowadays.

---

33 bit int? I don't care as long as it's fast. I just want to avoid UB and wrap.

I played with godbolt a little bit with these types. int was .long = 4 bytes, char .byte = 1 byte. Nothing new here. Clang created the best assembly out of icc/gcc/msyc.