anyhow, once I understood that unique_ptr meant nothing like its name but rather something like auto_free_pointer, the pieces sort of fell into place and I experienced almost no memory safety bugs while implementing the compiler, nor has afl-fuzz found any so far 4/5
Conversation
this is all despite my being a thoroughly mediocre C++ programmer. anyhow this story has no real point except that unique_ptr is actually pretty cool and useful, which I had not expected 5/5
11
5
97
Replying to
In the absence of Rust's shared borrows, how did you handle sharing access to the underlying object? Or did you simply not have any shared access?
1
3
Replying to
well, ugh. I don't know what best practices here are. I went ahead and shared addresses fairly freely. what I didn't share is ownership/deallocation responsibility.
2
6
what I mean is, I have no idea how I could create a working compiler without letting people borrow addresses/references all over the place. however, I made sure that all borrowers either made a copy or else forgot about what they had borrowed.
2
4
Replying to
Agreed.
Lots of interest in Rust's typesystem enforcing that specific behavior (forget or copy). How hard was it to maintain this discipline in C++ without that check?
2
3
Assignment, passing and returning in Rust works like C rather than C++. It has move semantics by default. If you try to use it after it was moved, you get an error and realize you need to either add a call to clone() or use a reference, and it prevent using dangling references.
1
2
In Rust, you end up using drastically more moves than in C++ along with substantially more lightweight references.
So, for example, using Rc<T> (thread-local shared pointer) or Arc<T> (cross-thread) in Rust is way cheaper because you use drastically more moves / references.
1
1
You have to implicitly call clone() to increase the reference count and you would only do that when you have to rather than it being the default and natural. The way you end up writing code is much different, *especially* with heavy use of views of vectors and strings.
1
1
This sounds a lot like deleting the copy constructor and assignment.
Let's implement:
-fno-copy-construction
that disables copy-constructor and assignment for full Rust experience.
1
Moving is an implicit default in Rust.
The important part is it's all memory safe due to the compiler preventing using anything after the lifetime ends.
It tracks the lifetime of references as part of their type to prevent using them beyond the scope of what they reference.
It also has to implement rules for aliasing. The general rule is that the usable mutable references (&mut) can't overlap. Normal immutable reference (&) can overlap. In terms of memory dependencies, references don't alias.
1
If you take deeper mut references, can't use the outer ones until those are gone. The language and libraries are designed around having lifetime checks and aliasing checks. Lifetime and aliasing rules also end up being the basis for not having data races, alongside Send / Sync.
1
Show replies