我对支持 Rc 或 Box 包装类型的 Rust 向量的理解是否正确？

Question

I'm not looking for code samples. I want to state my understanding of Box vs. Rc and have you tell me if my understanding is right or wrong.

Let's say I have some trait ChattyAnimal and a struct Cat that implements this trait, eg

pub trait ChattyAnimal {
  fn make_sound(&self);
}

pub struct Cat {
  pub name: String,
  pub sound: String
}

impl ChattyAnimal for Cat {
  fn make_sound(&self) {
    println!("Meow!");
  }
}

Now let's say I have other structs (Dog, Cow, Chicken, ...) that also implement the ChattyAnimal trait, and let's say I want to store all of these in the same vector.

So step 1 is I would have to use a Box type, because the Rust compiler cannot determine the size of everything that might implement this trait. And therefore, we must store these items on the heap – viola using a Box type, which is like a smarter pointer in C++. Anything wrapped with Box is automatically deleted by Rust when it goes out of scope.

// I can alias and use my Box type that wraps the trait like this:
pub type BoxyChattyAnimal = Box<dyn ChattyAnimal>;

// and then I can use my type alias, i.e.
pub struct Container {
  animals: Vec<BoxyChattyAnimal>
}

Meanwhile, with Box , Rust's borrow checker requires changing when I pass or reassign the instance. But if I actually want to have multiple references to the same underlying instance, I have to use Rc . And so to have a vector of ChattyAnimal instances where each instance can have multiple references, I would need to do:

pub type RcChattyAnimal = Rc<dyn ChattyAnimal>;

pub struct Container {
  animals: Vec<RcChattyAnimal>
}

One important take away from this is that if I want to have a vector of some trait type, I need to explicitly set that vector's type to a Box or Rc that wraps my trait. And so the Rust language designers force us to think about this in advance so that a Box or Rc cannot (at least not easily or accidentally) end up in the same vector.

This feels like a very and well thought design – helping prevent me from introducing bugs in my code. Is my understanding as stated above correct?

Answer 1

Yes, all this is correct.

There's a second reason for this design: it allows the compiler to verify that the operations you're performing on the vector elements are using memory in a safe way, relative to how they're stored.

For example, if you had a method on ChattyAnimal that mutates the animal (ie takes a &mut self argument), you could call that method on elements of a Vec<Box<dyn ChattyAnimal>> as long as you had a mutable reference to the vector; the Rust compiler would know that there could only be one reference to the ChattyAnimal in question (because the only reference is inside the Box , which is inside the Vec , and you have a mutable reference to the Vec so there can't be any other references to it). If you tried to write the same code with a Vec<Rc<dyn ChattyAnimal>> , the compiler would complain; it wouldn't be able to completely eliminate the possibility that your code might be mutating the animal at the same time as the code that called it was in the middle of trying to read the animal, which might lead to some inconsistencies in the calling code.

As a consequence, the compiler needs to know that all the elements of the Vec have their memory treated in the same way, so that it can check to make sure that a reference to some arbitrary element of the Vec is being used appropriately.

(There's a third reason, too, which is performance; because the compiler knows that this is a "vector of Box es" or "vector of Rc s", it can generate code that assumes a particular storage mechanism. For example, if you have a vector of Rc s, and clone one of the elements, the machine code that the compiler generates will work simply by going to the memory address listed in the vector and adding 1 to the reference count stored there – there's no need for any extra levels of indirection. If the vector were allowed to mix different allocation schemes, the generated code would have to be a lot more complex, because it wouldn't be able to assume things like "there is a reference count", and would instead need to (at runtime) find the appropriate piece of code for dealing with the memory allocation scheme in use, and then run it; that would be much slower.)