davidstone / bounded-integer

C++ library aiming to replace all built-in integers
Boost Software License 1.0
88 stars 3 forks source link

Loops and other runtime constructs #2

Open dumblob opened 1 year ago

dumblob commented 1 year ago

Since ever I wanted to have such integer available. The issue is I could not find any nice way how to handle loops with during-runtime-determined number of iterations. This holds also for other runtime constructs if any.

How do you handle operations with integers inside such loops?

davidstone commented 1 year ago

This is where containers::integer_range comes in: https://github.com/davidstone/bounded-integer/blob/main/include/containers/integer_range.hpp

The source of that run-time value needs to have some known bounds (unless it's potentially infinitely large, which I'm planning on supporting eventually). Then you can use it as

for (auto x : containers::integer_range(number_of_iterations)) {
}

or

for (auto x : containers::integer_range(first, last)) {
}

or even

for (auto x : containers::integer_range(first, last, step_size)) {
}

and this will give x the type that it needs to hold the valid integers in that range. In some ways, this just pushes the problem back, because you need to specify the type of, say, number_of_iterations. But that's a problem that exists today, we just tend to not think about it and just use either int or std::size_t, even when those might not be the best choice.

dumblob commented 1 year ago

unless it's potentially infinitely large, which I'm planning on supporting eventually

This is actually what I am after :wink:.

Do you have already some ideas how to approach it? Or do you just want to kind of "give up" and resort to bigint or alike?

davidstone commented 1 year ago

I'm going to add support for arbitrarily large integers with compile-time bounds, and those would be computed in the same way as anything else in the library. In addition to that, sometimes it makes sense to just go to unbounded, which I also plan on implementing at some point, but that would be a user decision. It may also make sense to have a hybrid type that functions like std::string's small-buffer optimization.

dumblob commented 1 year ago

It may also make sense to have a hybrid type that functions like std::string's small-buffer optimization.

Would this have any user-facing interface or will it be just an implementation detail?

Otherwise great news!