I am not sure why they chose to speculate about sizeof(int) in this way, vs. expressing the limit in terms of something more concrete.
I'll make sure to update the documentation.
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.
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 would you assume your observations are relevant to the use case?
> 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.
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.
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.