Использование Rc<T>{=html} для разделения данных
Вернемся к нашему примеру связного списка в Listing 15-5. Напомним, что мы определили его с использованием Box<T>. На этот раз мы создадим два списка, которые будут совместно владеть третьим списком. Концептуально это выглядит аналогично рисунку 15-3.
Рисунок 15-3: Два списка, b и c, совместно владеющие третьим списком, a
Мы создадим список a, содержащий 5, а затем 10. Затем мы создадим еще два списка: b, начинающийся с 3, и c, начинающийся с 4. Затем оба списка b и c будут продолжаться до первого списка a, содержащего 5 и 10. Другими словами, оба списка будут делиться первым списком, содержащим 5 и 10.
Попытка реализовать эту ситуацию с использованием нашей определения List с Box<T> не сработает, как показано в Listing 15-17.
Имя файла: src/main.rs
enum List {
Cons(i32, Box<List>),
Nil,
}
use crate::List::{Cons, Nil};
fn main() {
let a = Cons(5, Box::new(Cons(10, Box::new(Nil))));
1 let b = Cons(3, Box::new(a));
2 let c = Cons(4, Box::new(a));
}
Listing 15-17: Демонстрация того, что не разрешается иметь два списка с использованием Box<T>, которые пытаются совместно владеть третьим списком
При компиляции этого кода мы получаем следующую ошибку:
error[E0382]: use of moved value: `a`
--> src/main.rs:11:30
|
9 | let a = Cons(5, Box::new(Cons(10, Box::new(Nil))));
| - move occurs because `a` has type `List`, which
does not implement the `Copy` trait
10 | let b = Cons(3, Box::new(a));
| - value moved here
11 | let c = Cons(4, Box::new(a));
| ^ value used here after move
Варианты Cons владеют данными, которые они хранят, поэтому когда мы создаем список b [1], a перемещается в b, и b становится владельцем a. Затем, когда мы пытаемся снова использовать a при создании c [2], мы не имеем права hacerlo, потому что a уже перемещено.
Мы могли бы изменить определение Cons для хранения ссылок вместо этого, но тогда мы бы должны указать параметры времени жизни. Указывая параметры времени жизни, мы бы указали, что каждый элемент в списке будет жить по крайней мере столько же времени, сколько и весь список. Это справедливо для элементов и списков в Listing 15-17, но не во всех сценариях.
Вместо этого мы изменим наше определение List для использования Rc<T> вместо Box<T>, как показано в Listing 15-18. Теперь каждый вариант Cons будет хранить значение и Rc<T>, указывающий на List. Когда мы создаем b, вместо взятия владения над a, мы скопируем Rc<List>, которое хранится в a, тем самым увеличив количество ссылок с одного до двух и позволяя a и b совместно владеть данными в этом Rc<List>. Мы также скопируем a при создании c, увеличивая количество ссылок с двух до трех. Каждый раз, когда мы вызываем Rc::clone, счетчик ссылок на данные внутри Rc<List> будет увеличиваться, и данные не будут удалены, пока не останется ноль ссылок на них.
Имя файла: src/main.rs
enum List {
Cons(i32, Rc<List>),
Nil,
}
use crate::List::{Cons, Nil};
1 use std::rc::Rc;
fn main() {
2 let a = Rc::new(Cons(5, Rc::new(Cons(10, Rc::new(Nil)))));
3 let b = Cons(3, Rc::clone(&a));
4 let c = Cons(4, Rc::clone(&a));
}
Listing 15-18: Определение List, которое использует Rc<T>
Мы должны добавить инструкцию use, чтобы подключить Rc<T> к области видимости [1], потому что оно не находится в прелюдии. В main мы создаем список, содержащий 5 и 10, и сохраняем его в новом Rc<List> в a [2]. Затем, когда мы создаем b [3] и c [4], мы вызываем функцию Rc::clone и передаем ссылку на Rc<List> в a в качестве аргумента.
Мы могли бы вызвать a.clone() вместо Rc::clone(&a), но в Rust принято использовать Rc::clone в этом случае. Реализация Rc::clone не делает глубокую копию всех данных, как это делает реализация clone для большинства типов. Вызов Rc::clone только увеличивает счетчик ссылок, что не занимает много времени. Глубокая копия данных может занять много времени. Используя Rc::clone для подсчета ссылок, мы можем визуально различать виды глубоких копий и виды копий, которые увеличивают счетчик ссылок. При поиске проблем с производительностью в коде мы должны учитывать только глубокие копии и можно не обращать внимание на вызовы Rc::clone.
