Understanding Memory Management, Part 5: Fighting with Rust

No wrestling, pure enjoyment:

#include <vector> #include <iostream>

int main() { std::vector<int> vec = {1, 2, 3}; vec.reserve(3);

    std::cout << "Initial capacity: " << vec.capacity() << std::endl;  
    std::cout << "Initial data address: " << (void*)vec.data() << std::endl;  

    int* ptr = vec.data();  

    std::cout << "Pointer before push_back: " << (void*)ptr << std::endl;  
    std::cout << "Value via pointer before push_back: " << *ptr << std::endl;  

    std::cout << "\nPushing back 4...\n" << std::endl;
    vec.push_back(4);  

    std::cout << "New capacity: " << vec.capacity() << std::endl;  
    std::cout << "New data address: " << (void*)vec.data() << std::endl;  

    std::cout << "\nAttempting to access data via the old pointer..." << std::endl;  
    std::cout << "Old pointer value: " << (void*)ptr << std::endl;  
    int value = *ptr;  
    std::cout << "Read from dangling pointer (UB): " << value << std::endl;  

    return 0;  

}

./a.out Initial capacity: 3 Initial data address: 0x517d2b0 Pointer before push_back: 0x517d2b0 Value via pointer before push_back: 1

Pushing back 4...

New capacity: 6 New data address: 0x517d6e0

Attempting to access data via the old pointer... Old pointer value: 0x517d2b0 Read from dangling pointer (UB): 20861

> wrestle the compiler

This is quite literally a skill issue, no offense.

'wrestle the compiler' implies you think you know better; this is usually not the case and the compiler is here to tell you about it. It's annoying to be bad at tracking ownership and guess what: most people are. The ones who aren't have decades of experience in C/C++ and employ much the same techniques that Rust guides you towards. If you really know better, there are ways to get around the compiler. They're verbose and marked unsafe to 1) discourage you from doing that and 2) warn others to be extra careful here.

If this is all unnecessary for you - and I want to underscore I agree it should be in most software development work - stick to GC languages. With some elbow grease they can be made as performant as low level languages if you write the critical parts in a way you'd have to do it in Rust and will be free to write the rest in a way which doesn't require years of experience tracking ownership manually. (Note it won't hurt to be tracking ownership anyway, it's just much less of an issue if you have to put a weakref somewhere once a couple years vs be aware at all times of what owns what.)

> I can't find an explanation in the Rust documentation but I expect the reason is that someone could implement another trait that provides .into_iter() on whatever the x is in for y in x, thus resulting in a compiler error because there would be two candidate implementations.

Because nothing in Rust is identifier-based. Unlike python, all syntax magic (even the ? operator) relies on traits defined by `core`.

    for x in y {

desugars to

    let mut iter = IntoIterator::into_iter(y);
    while let Some(x) = y.next() {

and

    x?

desugars to

    match x {
        Ok(x) => x,
        Err(e) => {
            return Err(From::from(e));
        }
    }

and

    x + y

desugars to

    core::ops::Add::add(x, y)

etc.

All of those traits are expected to live explicitly in the core crate at well known paths. Otherwise you'd be writing methods with absolutely no idea how the language would interact with it. And if you had a Set type implement `add`, it'd have to accept exactly 2 arguments to be compatible with the language's `add` or something equally as unergonomic.

It's traits all the way down! There'd be no explanation needed because it'd be antithetical and contradictory to traits to begin with. Once one understands how traits are intended to be used, the explanation for why there aren't identifier based resolution semantics becomes obvious.

> this is all complexity and refactoring pain that Rust hoists onto every programmer every day

This is what you should be doing when working with C/C++, except there is no compiler to call you names there if you don’t.

If you’re saying ‘use a GC language unless requirements are strict about it’, yeah hard to disagree.

I see why you're saying that, and i almost entirely agree with you. However, i would say that if all you're doing is glueing calls to third party systems (like what most backend code is), then you won't fall into complex lifetime problems anyway, and the experience will remain quite pleasant.

Another point, is that the rust ecosystem is absolutely insanely good ( i've recently worked with uniffi and wasmbindgen, and those are 5 years ahead of anything else i've seen..)

I'm coming from C++ now I don't want to use C++ anymore. When C++ was still my primary language I always frustrated with some of its feature like non-destructive move, copy by default and dangling references then I found Rust fixed all of those problems. At the beginning I very frustrated with Rust because the borrow checker prevent me from doing what I usually do in C++ but I keep going.

Im sure it is. I don’t know how to program but read most of part 4 when it appeared here last.