undefined | Better HN

0 pointsest313y ago0 comments

It will still implement that with a loop over the array where there is a (bounds) check for the integer when it's being incremented (the i < len in int i; for(i = 0; i < len; i++)). That's no different from a loop over a slice, both of which eliminate the bounds check in the body of the loop (the one in list[i]). Arrays do have an advantage however, compilers can see their size so if you have an array (or array reference) and index it with a constant, then that bounds check will be eliminated. Also, array references are cheaper than slices because slices always contain the length.

0 comments

nindalf3y ago

> Arrays do have an advantage however, compilers can see their size

Wouldn’t vectors have the same advantage in Rust? If we’re iterating over a vector, it’s proveable at compile time that the length is not being modified during the iteration.

brundolf3y ago

Length not being modified during iteration sure, but not the exact length. It's not possible in the general case to determine the exact length of a Vec at compile time, whereas Rust arrays can never change length so their exact length is know statically (unless you've got a slice, which is different)

ReactiveJelly3y ago

I think they mean a one-off constant index should never check.

    let arr = [1, 2, 3, 4];
    // Will not compile a bound check
    let x = arr [3];
    
    let v = vec! [1, 2, 3, 4];
    // Imagine other code separates these two lines
    // Might compile a bound check
    let x = v [3];

clarkmoody3y ago

In this case, v is not declared mutable, so you could ignore. In fact, the compiler will probably end up assigning x = 4 at compile time.

1 more reply

j / k navigate · click thread line to collapse