Help understanding this exercise

[anon81327159]

Even though they mention just one pointer in the text, I think they actually are saying the same than you, because the iterator is represented as a Range in the drawings that they include and shows both begin and end.

I mean this section in case you're interested corroborating https://rust-book.cs.brown.edu/ch08-01-vectors.html#safely-using-iterators

[khimru]

@anon81327159

Could it be because .iter() isn't accessing through v (like in the example you added), but is a direct pointer to the data &v[..]?

I think that's the best level of understanding for you, at this point. It's not an actual truth, but the closest approximation of truth that someone without years of experience programming in other languages would have.

The issue with that question is that it's, again, question directed toward someone with years of experience in C++, who suffered a lot from similar issues in C++ equivalent code and may appreciate what Rust does for them.

But to understand why this code shouldn't be allowed one have to know about intimate details of how iter is implemented, about how remove and shrink_to_fit are implemented and so on. If you know C++ (or even C) you would know the answers, if you come without such baggage then the whole question just becomes a riddle wrapped in a mystery inside an enigma.

[jumpnbrownweasel]

@anon81327159

Could it be because .iter() isn't accessing through v (like in the example you added), but is a direct pointer to the data &v[..]?

Yes! A Vec contains a pointer plus to usize fields: length and capacity. If the pointer changes due to reallocation, the code I posted accesses the new pointer via the Vec structure. But using an iterator will continue to access the old (deallocated) pointer.

There is a diagram in "the book" describing the memory layout of a String, which is similar to a Vec, so this may help. Scroll down a little from here:
https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html#variables-and-data-interacting-with-move

@anon81327159

It is clear though why they are using reverse it is because that makes accesses always within the boundaries of the vector. (I think but please correct?)

Right! And that's also why the code I posted (using a reversed range of indexes) works.

[00100011]

@jumpnbrownweasel

There is a diagram in "the book" describing the memory layout of a String, which is similar to a Vec, so this may help. Scroll down a little from here:
What is Ownership? - The Rust Programming Language

Since we're talking about diagrams, this thing here feels like an obligatory plug.

[quinedot]

@00100011

Since we're talking about diagrams, this thing here feels like an obligatory plug.

It's a great diagram, but note many of the exact details are implementation details; e.g. Mutex<T> is no longer boxed on most (but not all) platforms. Aside from field order, the Vec<_> and &[_] parts are guaranteed, though.^[1]

---

1. The Vec<_> pointer might not point to the heap in the case of zero sized types or zero capacity. ↩︎

[anon81327159]

thanks

marking as solution because it explains it better, and has a useful link as well.