Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loops and other runtime constructs #2

Open
dumblob opened this issue Oct 13, 2022 · 4 comments
Open

Loops and other runtime constructs #2

dumblob opened this issue Oct 13, 2022 · 4 comments

Comments

@dumblob
Copy link

dumblob commented Oct 13, 2022

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
Copy link
Owner

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
Copy link
Author

dumblob commented Oct 17, 2022

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

This is actually what I am after 😉.

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
Copy link
Owner

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
Copy link
Author

dumblob commented Nov 8, 2022

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants