These are Rust's rules for the Borrow Checker.
Isn't the first rule really just RAII from C++? That would mean RAII is sufficient to stop use after free bugs, right?
And the second rule stops data races, but data races are not necessarily a bug.
 Ape Out Shirt $21.68 |
 UFOs Are A Psyop Shirt $21.68 |
Ape Out Shirt $21.68 |
>Second, you may have one or the other of these two kinds of borrows, but not both at the same time:
can you read op?
absolute state of 4chin nowadays
2nd rule of only 1 mutable reference prevents UB due to strict aliasing and iterator invalidation
>2nd rule of only 1 mutable reference prevents UB due to strict aliasing and iterator invalidation
>hey look at me! im spitting out random complicated words! im smart!
no. in rust if you try
let mut foo = String::from("frick op");
something = bar(&foo);
else = bar2(&foo);
it won't compile
what the frick are you talking about?
1. you're missing the let keyword on noth vars
2. else is a reserved keyword so the last variable name is just wrong
what does this have to do with what op said?
No. The following is valid C++. Note that the function returns a reference (borrow) to something that's destroyed at end of function.
int& f() {
std::vector v{0};
return v[0];
}
Thanks that makes sense.
What about the heap? Would forcing return by value on the stack, and RAII on heap avoid use after free bugs?
Like, what's the use case for returning a pointer to stack memory addresses?
If a language just totally disallowed returning a pointer to stack memory addresses (but allowed heap for obvious reasons), what exactly would be lost?
>what exactly would be lost?
Nothing. In the example, the reference is pointing to heap though (assuming no small size optimization).
Oh I see, I'm used to pure C so I assumed that std::vector would be all on stack (like an array) or all on heap - but the header is on stack and the elements are on heap by default, which seems like a bad idea
If the object was allocated purely on heap though, there is no problem right? The "name" would fall out of scope, but the object itself would still be alive right?
Not him but Rust has stack allocated arrays too, vector is a different data structure.
C++ std containers use RAII, which means the heap memory gets deleted (ie freed) right when the "name" exits scope.
You could replace std::vector with std::unique_ptr (which is just a pointer to heap).
So if you disallow pointer returns completely, and combine with RAII, then it mimics the first rule for the Rust Borrow Checker right?
Pretty much, yes. You still need to be careful while writing copy/move constructors for classes that use heap though, or just use std containers that handle the difficult stuff for you.
I see, and the main difference between this and pure C is thus that malloc() would have infinite lifetime unless you manually free (instead of having scope based rules like RAII or Rust), and if you lose reference to the allocated memory without freeing, it just leaks and takes up RAM pointlessly
Yes, that's right.
Long-running C programs usually end up manually doing RAII or allocate resources right at program start.
>You could replace std::vector with std::unique_ptr (which is just a pointer to heap).
* and the example would work just the same: return a reference to freed memory.
>Isn't the first rule really just RAII from C++?
lol what? no?
this is why IQfy should never be allowed to comment on the rust programming language
Memory safety janny filters another one.
>having to ask permission to "borrow" resources from your computer
built for gcc
lol imagine using a non GC'ed language
sorry virgins I spend my time actually solving problems instead of keeping track of memory
>exactly one mutable reference
>no circular references, for your """safety"""
trash