so I had never really thought too hard about C++'s unique_ptr abstraction, except to be vaguely annoyed that it so obviously failed to enforce anything remotely resembling what its name appears to promise 1/5
Conversation
anyhow, recently I needed to implement a compiler for the language that and I are using for our spring compiler class, and I decided to use C++ and also to take unique_ptr seriously in the implementation 2/5
1
18
the other data structures from the library that I'm using are vector and unordered_map, which I already liked perfectly well, they are both very nice abstractions 3/5
1
15
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
6
4
47
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.
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
Show replies