Conversation

Patricia Aas

@pati_gallardo

May 13, 2021

I don’t know Rust, so I was wondering how this would look in C++, does anyone have an example?

Quote Tweet

Patrick Walton

@pcwalton

May 13, 2021

Conceptually, the thing that makes Rust different from modern C++ (and other languages) is the "alias xor mutable" guideline, enforced by the borrow check. You could write C++ that way, but in practice nobody does. It's much stricter than just using smart pointers.

Show this thread

Replying to

You can have any number of immutable views (references) of data but only one mutable reference at a time. The compiler also enforces that the references can't be used beyond the lifetime of the object and the lifetime scopes are part of the types of references (as subtypes).

Replying to

and

Mutex<T> and RwLock<T> naturally provide a dynamic implementation of those checks as part of implementing their interior mutability. Those give out objects representing locks with the destructor releasing the lock, similar to a modern C++ idiom, but safe.

Replying to

and

RefCell<T> is similar within a single thread with dynamic failure on conflicts rather than waiting for the lock to be released. It's used in cases where statically checked borrow checking is too strict and can only support immutability due to shared ownership.

Replying to

and

Arc<T> is comparable to std::shared_ptr<T>. Rc<T> is a thread-specific variant of it without the atomic reference counting. Due to the shared ownership, those only provide immutable references. Arc<Mutex<T>> and Rc<RefCell<T>> provide a way to have shared ownership + mutability.

Replying to

and

The only way you can have overlapping references with mutability is via very restricted internal mutability via &Cell<T>. RefCell<T> is more flexible (allows references) but has to enforce the usual unique mutable reference rule dynamically. doc.rust-lang.org/std/cell/

Replying to

and

Vast majority of code can happily get by with nearly everything having unique ownership and using lots of lightweight &T and &mut T references. Using Rc<T>, etc. is rarer than std::shared_ptr<T> in modern C++. References are safe so you tend to use them much more than in C++.

Replying to

and

Similarly, in Rust, moves are the default rather than copies and moves are simply always a shallow copy by the compiler. Clone trait (clone method) is comparable to a C++ copy constructor. For Rc<T>, that increments the reference count. You can normally just move them around.

Replying to

and

In particular, in Rust, you heavily use array and string views (slices) which are references to [T] and str. C++17 adds std::string_view but you couldn't heavily use that kind of approach without lots of use-after-free bugs. Typical in Rust to return views into views into views.

Replying to

and

You essentially already know how to work with all of it and the syntax for all of this is very familiar coming from C++ too. It's mostly a matter of getting used to using tons of tagged unions and the lifetime + non-aliasing mutable reference rules. It's easy for C++ programmers.

9:16 AM · May 13, 2021Twitter Web App

Replying to

and

Rust might be hard for other people to pick up but someone familiar with modern C++ is almost completely at home and it all makes a lot of sense. Takes time to get used to those rules though. Have to learn how to design around it well rather than resorting to many Rc<RefCell<T>>.

Replying to

I think I should learn it to get a feel for this way of thinking. I tend to use the stack a lot and values and const ref, when I really need custom heap allocations I do that with unique_ptr. This seems very “shared heap memory oriented” 🤔 I try to share as little as possible…

Show replies