- cross-posted to:
- rust@kbin.social
- learn_programming@programming.dev
- cross-posted to:
- rust@kbin.social
- learn_programming@programming.dev
Rust lets you do efficient reference-counted strings and dynamic arrays using Arc basically just as easily as their owning (and deep-cloning) equivalents, String and Vec respectively. So why not use them as a reasonable default, until you actually need the mutability that String and Vec provide? Get into the weeds with me here, feat. some cool visualizations, with special guest appearance from Box.
This video assumes some familiarity with Rust and its core smart pointer types, namely Vec/String/Rc/Arc/Box, along with data structures like HashMap and BTreeMap, and traits like Clone, Hash, Ord, and serde::{Serialize, Deserialize}.
serde feature flag for Rc/Arc
Arc docs
Vec docs
Smart pointers in Rust • Crust of Rust
animations
If the data represented in the Arc is supposed to be immutable, why not pass around a reference of
Vec<T>
instead of cloning theArc<[T]>
over and over? The latter appears more expensive.Arc<String>
is always going to be worse thanArc<str>
becauseArc<String>
is roughly equivalent toArc<Vec<char>>
. Lastly, instead of the overhead of a tuple struct, we could definepub type MonsterId = Arc<str>;
and maybe define and implement traits on it for additional methods.
Nitpick: it’s
Vec<u8>
, notVec<char>
.Gee thanks, nice catch!