The author probably meant the largest available integral type, which can be __int128 on gcc and clang.

Library author here. I'm sorry you found the wording confusing. I was trying to talk generally about the non-library types: things like int and long. The C++ standard guarantees that there exists an integer type that is at least 64-bits large (`long long` and `unsigned long long`), and many platforms support a type like __int128 that is 128 bits large. Unfortunately, the documentation is slightly out of date. clang has some bugs that cause the compiler to crash if you use __int128 or __uint128 in certain situations (which my library uses), so I had 128-bit support on only in gcc. However, my library is currently making use of C++20 concepts, and only a branch on clang supports that enough, so the master version of my library can be compiled only by clang, so the largest size currently allowed is a 64-bit integer (either signed or unsigned, the library handles that for you).

I'll make sure to update the documentation.

Intel supports them depending on the processor.

SSE2 has native 128-bit math, AVX has 256-bit native integer math, and AVX-512 has 512-bit integer math.

See https://en.wikipedia.org/wiki/AVX-512

The Intel compiler supports these types.

How are you envisioning this library being used?

What?

I am saying the author did not express the limitation well, and instead made it sound like they don't understand sizeof(int). The explanation that leni536 offered makes a lot more sense, so maybe they should have put it that way instead of using an easily misunderstood term as "built-in integer" to mean "one of several integer types that we may choose based on some ifdef"

Why did you arrive at this confusion?

Why would you assume your observations are relevant to the use case?

Did you read this part:

> bounded::integer uses built-in integers as the template parameter to determine its bounds. This means that it cannot store an integer larger than ...

They say the limitation arises from using "built-in integers" as template parameters. It is reasonable to assume "built-in integer" means "int". It is more a stretch to assume "built-in integer" means any number of types depending on the evaluation of several ifdefs [which is what I found in the source].

There is nothing about a "use case" relevant to any of that quoted statement, so I find your reply very confusing too.

> It is reasonable to assume "built-in integer" means "int".

This strikes me as a little nuts for C but it definitely explains this thread. I just assumed people had already switched over to e.g. sint32/size_t to avoid this problem a long time ago. I couldn’t tell if this was a legitimate complaint or someone’s language lawyering tendencies gone too far.

First of all, we're not talking C. This is a C++ template parameter. The feature doesn't exist in C.

Second, it is not "nuts" to use int, I would argue it's quite a bit more crazy to use rarely-supported 128-bit quantities when you don't need them. Your suggestion of "sint32" (this is not a standardized typedef, you mean int32_t perhaps) would be the same as int on most compilers today, and size_t is likewise very often 32 bits. Your suggestion is basically a no-op in a lot of places. Domain-specific areas like file formats or network protocols are a different story, as those have to be explicit about specifying sizes.

Third:

> someone’s language lawyering tendencies

I suggest you avoid passive-aggressive communication style and just say "you" instead of "someone". If you're going to criticize or give feedback, be direct. Don't vaguely tell me that "somebody" "might" have a problem.

Best regards to you, friend.

Hey I was just trying to figure out if you were bringing up anything of value :)