Ohh
Conversation
This statement in the reference for "slice" is what I want, but also it is bad. Are there (safe) steps I can take to reliably ensure bounds-checking for a particular use of a slice is removed before runtime? Are the rules for this documented somewhere (such as the rustc manual)?
6
4
Like what I'm looking for is some way to type or decorate a site such that I'm asserting "I think I followed the rules to get a no-boundcheck optimization here, and if I messed up, I want the compiler to tell me so"
4
8
Several people replying "use iterators". Good approach, but here's a complication:
I often find myself in a situation where I have 2 arrays, incidentally of the same length.
int a:[T], b:[T];
I want to iterate over "both at once". For example produce a c such c[i] = a[i] + b[i]
1
7
Using the iterator syntax (which remember, I want to use because I want the language-level guarantee I'm avoiding bounds checks), is there a way to iterate over 2 arrays (or iterate up to end of shorter array)? In C I'd do this by iterating over key range and random indexing.
7
5
Replying to
Iterators are almost entirely library feature. The language provides some syntactic sugar via `for` loops.
The standard library's slice iterator has start and end pointers with the core iterator next method implemented as advancing by an element and comparing to the end pointer.
1
1
Replying to
If it happens to be the case that the standard library iterators will always follow the code path that removes the bounds checks at individual index sites, and this is a strong and universally understood social contract, that's "as good as" a lang guarantee for now i think
4
3
Yeah it's pretty widely understood in the community that if you're using iterators, you'll get bounds checks elided -- and any cases where that doesn't happen are a compiler bug
2
2
There aren't bounds checks to elide for the slice iterator. It's not that they're being elided but rather that the library implementation of the slice iterator uses a start and end pointer with unsafe code so you end up with the same kind of code as with a pair of C++ iterators.
3
1
1
right; the check occurs once at creation, and then the ref/mut exclusion principle forbids that check from becoming invalid while the iterator is alive
1
At creation it grabs the start + end pointers and then it maps perfectly to the iterator protocol where checking for None is a very thin wrapper around checking that the start and end pointers aren't equal. So, for slices, it just doesn't have bounds checks to optimize away.
doc.rust-lang.org/beta/std/marke was added to properly encapsulate what it's doing because the old way lifetimes worked without it wasn't quite correct when I initially made the low-level slice iterator.
The first example is basically the standard library's slice iterator implementation.