C++ type system AKA what is exactly int ?

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Sesse
Posts: 274
Joined: Mon Apr 30, 2018 9:51 pm
Contact:

Re: C++ type system AKA what is exactly int ?

Post by Sesse » Tue Feb 16, 2021 8:33 pm

Bo Persson wrote:
Mon Feb 15, 2021 8:41 am
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
Posts: 12012
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: C++ type system AKA what is exactly int ?

Post by Dann Corbit » Thu Feb 18, 2021 6:08 am

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.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

User avatar
Bo Persson
Posts: 188
Joined: Sat Mar 11, 2006 7:31 am
Location: Malmö, Sweden
Full name: Bo Persson

Re: C++ type system AKA what is exactly int ?

Post by Bo Persson » Thu Feb 18, 2021 8:12 am

Dann Corbit wrote:
Thu Feb 18, 2021 6:08 am
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
Posts: 12012
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: C++ type system AKA what is exactly int ?

Post by Dann Corbit » Thu Feb 18, 2021 7:24 pm

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.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

Sesse
Posts: 274
Joined: Mon Apr 30, 2018 9:51 pm
Contact:

Re: C++ type system AKA what is exactly int ?

Post by Sesse » Fri Feb 19, 2021 7:52 am

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
Posts: 12012
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: C++ type system AKA what is exactly int ?

Post by Dann Corbit » Sat Feb 20, 2021 2:56 am

I think the shift to 128 bits will be driven by:
1. Need for fast arithmetic.
Cryptography
Graphics
2. File systems
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

JohnWoe
Posts: 318
Joined: Sat Mar 02, 2013 10:31 pm

Re: C++ type system AKA what is exactly int ?

Post by JohnWoe » Sat Feb 20, 2021 9:44 am

mvanthoor wrote:
Sun Feb 14, 2021 10:45 pm
JohnWoe wrote:
Sun Feb 14, 2021 9:10 pm
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.

User avatar
Bo Persson
Posts: 188
Joined: Sat Mar 11, 2006 7:31 am
Location: Malmö, Sweden
Full name: Bo Persson

Re: C++ type system AKA what is exactly int ?

Post by Bo Persson » Sun Feb 21, 2021 8:28 am

JohnWoe wrote:
Sat Feb 20, 2021 9:44 am
mvanthoor wrote:
Sun Feb 14, 2021 10:45 pm
JohnWoe wrote:
Sun Feb 14, 2021 9:10 pm
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.

Post Reply