Live data from Hacker News

Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

bitbucket.org

21–30 of 130 posts

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#21
post #11

Earlier quoted context omitted.

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?

int, long. The standard specifies their minimum sizes.

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.

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#22
post #11

Earlier quoted context omitted.

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?

int, long. The standard specifies their minimum sizes.

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

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#23

> The built-in integer types in C++ (int, unsigned, long long, etc.) are mostly unusable because of the lax requirements on bounds. This must be some new definition of the word 'unusable.'

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?

You can store year 1850-2050 in a byte.

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#24
post #20

Earlier quoted context omitted.

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.

You can build portable libraries on top of nonportable primitives.

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#25

Earlier quoted context omitted.

I am not aware of any compiler or platform where int is 128 bits. The most common these days, even on 64 bit platforms, is 32 bits, which they don't even mention. 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.

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"

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#26

> The built-in integer types in C++ (int, unsigned, long long, etc.) are mostly unusable because of the lax requirements on bounds. This must be some new definition of the word 'unusable.'

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.

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#27
post #18

Maybe Ada's approach of every number type requiring explicit bounds is a good one.

Or Lisp’s approach of just using ”big” ints by default (which is practically the same but with an implicit default of “infinity”). And trust the compiler to use fixints internally when the programmer has declared it safe to do so.

But that performs very poorly on all architectures.

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#28

> The built-in integer types in C++ (int, unsigned, long long, etc.) are mostly unusable because of the lax requirements on bounds. This must be some new definition of the word 'unusable.'

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?

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#29
post #20

Earlier quoted context omitted.

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

Re: Bounded Integer: Header-only C++ library replaces integers, adds explicit bounds

#30
At this point, when I see libraries like this all I can think is ”oh good, my compile times aren’t long enough, lets make EVERY INTEGER a template”.

Also, while I can reasonably beliveve that most of the overhead goes away at -O2 or -O3, this has to just trash performance for debug builds, which is not unimportant.

Post reply on HN