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
So good that, in my quite limited understanding of Rust it sounds like everything nontrivial by default is basically a unique_ptr.
2
2
The static enforcement of rules for move semantics and reference aliasing/lifetimes is the interesting part.
Box<T> benefits from those in the same way as any other type. It's quite boring in the Rust world. Any type with a destructor has similar semantics.
1
2
A major difference from C++ in Rust is that assignment, passing and returning values works like C. If the type has a destructor, those have move semantics. A non-trivial copy is done by calling clone explicitly. Rust code uses far more moves and lot more lightweight references.
2
3
I really need to start writing Rust, but it always seems that there's something more pressing to learn
1
2
I don't think you'll really have as much to learn as you think.
As a C++ programmer with a deep familiarity with how memory corruption happens and the semantics you need to avoid it, you largely have an informal and imperfect form of Rust's borrow checker in your head already.
this is what I always hope. I almost hate to be proved wrong though.
The main you need to learn is not really syntax, semantics, etc. of the language and libraries. That all comes quite naturally... but rather, you need to learn the idioms needed to work around the static checking. You want to do something and it won't let you. Need to satisfy it.
2
3
this is my experience writing OCaml, where there's always a simple way to do what I want but it takes me all day to find it
1
2
Show replies