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>>.
Conversation
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…
2
Replying to
Rust encourages heavily uses the stack and you're pushed towards designing around unique ownership more than C++. You use lightweight references a lot more aggressively though, particularly with arrays/strings.
Shared ownership + mutability is very restricted and kinda painful.
2
2
Replying to
“You use lightweight references a lot more aggressively though, particularly with arrays/strings.”
What would similar code in C++ look like?
1
Replying to
It's basically just the same thing but with moves as the default and references everywhere. So, for example, if you're splitting a string in Rust, the natural way to do that is an iterator (reference) of string slices (more references) and then taking more slices of those, etc.
1
2
It doesn't really look different, it's just that moves are the default and references are the normal way to do everything unless you absolutely need to do a copy:
doc.rust-lang.org/std/string/str
If you want to copy a view to an allocation, you'd call s.to_owned().
1
2
So, for example, it's really natural to do complex parsing with multiple layers without allocating any new strings but rather taking views into views into views. It's not something weird but rather the most natural and easiest approach. If you want to allocate, that's explicit.
1
2
It's more like C than C++ in terms of copying and allocation. Assigning, passing parameters and returning is always a shallow copy like C. If the type has a destructor, that's a move of ownership. There is no move constructor concept, etc. though and it just works like C values.
1
2
References are also more like C pointers (but safe and non-null) than C++ references. They're simply regular values / types. &[T] and &str (slices) are also just a case of &T. Box<[T]> (rarely used) can be converted to/from Vec<T> (converting from it drops excess capacity first).
1
2
Most functions working with strings use them via &str, and similar with arrays. Rust's String is like std::string and Vec<T> is like std::vector<T>. They are far more interoperable with each other, references and smart pointers though.
1
2
So, for example, you can go from Box<[u8]> or Vec<[u8]> to String without allocation. It just has to check that it's valid UTF-8 and can make it a String.
You usually write code via references because it's simpler and reusable. Similarly, slices, not references to String, etc.
You wouldn't take references to String (&String) because then that doesn't work directly with string constants or views. You build around references/slices whenever possible, and then that just ends up naturally chaining together with a lot less allocation than you do in C++.
1
2
An API to parse a number from a string will naturally take a &str parameter. So, it's natural to be passing in a view to that. It doesn't care if the &str points into a String, a string constant (&str with static lifetime) or where it came from (multiple layers of slicing, etc.).
1
2
Show replies