Кратко — с пояснениями и примерами.
Что это и базовые правила
- Ownership: каждое значение в Rust имеет ровно одного владельца; при присвоении/передаче без типа Copy происходит перемещение (move), старый идентификатор перестаёт быть доступен. Это даёт автоматический RAII-подобный drop без сборщика мусора.
Пример: `let v = vec![1,2]; let v2 = v; // v больше нельзя использовать`
- Borrowing: можно брать ссылки `&T` (неконстр.) или `&mut T` (мутаб.). Правила:
- любое число неизменяемых ссылок `&T` или ровно одна изменяемая `&mut T`;
- нельзя одновременно иметь `&mut` и какие-либо `&`.
Это обеспечивает отсутствие гонок данных и неопределённого поведения при безопасном коде.
- Lifetimes: аннотации времени жизни (`'a`) выражают зависимость живучести ссылок; компилятор проверяет, что ссылки не «выходят» за время жизни объекта. Часто эллизионные правила скрывают аннотации, но в сигнатурах/структурах они нужны:
Пример struct: `struct Foo { r: &'a i32 }`.
Хранение общих структур данных — шаблоны в Rust
1) Несколько владельцев в однопоточном контексте
- Rc для shared ownership + RefCell для interior mutability:
Пример (узел графа, простой):
```
use std::rc::{Rc, Weak};
use std::cell::RefCell;
struct Node { value: i32, children: Vec<Rc<RefCell>> }
let a = Rc::new(RefCell::new(Node { value: 1, children: vec![] }));
let b = Rc::new(RefCell::new(Node { value: 2, children: vec![a.clone()] }));
a.borrow_mut().children.push(b.clone()); // создаёт цикл -> утечка Rc
```
- Важно: циклы `Rc` приводят к утечке памяти (счётчик ссылок никогда не дойдёт до нуля). Чтобы избежать — использовать `Weak` для «обратных» ссылок:
```
parent: Vec<Weak<RefCell>> ```
2) Многопоточный доступ
- Arc вместо Rc; для мутабельности внутри Arc — Mutex или RwLock:
`Arc<Mutex>` или `Arc<RwLock>`. Это обеспечивает атомарный счётчик и синхронизацию.
3) Interior mutability
- RefCell (runtime borrow checking в однопоточном коде) бросает panic при нарушении заимствований; Cell/RefCell/Mutex позволяют изменять данные, даже если у вас только неизменяемый владетель.
4) Self-referential структуры
- Структура, содержащая ссылку на собственную область памяти (например, указатель на внутренний буфер), при перемещении может сломать ссылку. В Rust это по умолчанию нельзя безопасно сделать; решение — использовать Box + Pin или хранить индексы/offset'ы вместо ссылок, либо использовать unsafe и Pin:
- Простое правило: self-referential struct без Pin — невалидна в безопасном Rust.
Где привычные приёмы C++ становятся невозможны или опасны (и почему Rust этого не позволяет)
- Двойное владение и явное delete: в C++ можно несколько раз delete или забыть delete → UB/утечки. В Rust владение и автоматический drop по одному владельцу исключают double-free/USE-AFTER-FREE в safe-коде.
- Возвращение ссылки на локальную переменную: в C++ компилятор не всегда ловит, в Rust это запрещено компилятором (lifetime error).
Пример запрещённого:
```
fn bad() -> &i32 {
let x = 5;
&x // ошибка: возвращается ссылка на локальную переменную
}
```
- Множественные мутабельные алиасы: в C++ можно иметь несколько указателей и мутировать память — UB (data race). Rust запрещает это в safe-коде: либо один `&mut`, либо много `&`.
- Перехитрить проверку через reinterpret_cast / type punning: в Rust safe-коду это недоступно; unsafe даёт ту же опасность, но владелец unsafe-кода берёт ответственность.
- Скрытые зависимости жизненного цикла (use-after-free): C++ допускает, Rust предотвращает проверкой lifetimes.
- Сложные паттерны: intrusive linked lists (вставка элемента, который хранится в сторонней структуре) — в Rust сложнее без unsafe, потому что элемент не должен содержать «сырые» указатели в сторону того, кто его хранит. Аналогично self-referential и coroutine-local pointers.
- Асинхронность: future, содержащий ссылку с коротким lifetime и вызываемый через `.await` — нельзя, если future может быть перемещён через await point; часто требуется `'static` или использовать `Pin`/владелец данных.
Короткие рекомендации при переработке C++-паттернов в Rust
- Для shared ownership: Rc<RefCell> (однопоточно), Arc<Mutex> (многопоточно); для обратных ссылок — Weak.
- Для производительности и избежать runtime-checks: по возможности проектировать без RefCell (использовать ownership и перемещения, индексы вместо ссылок).
- Для self-referential/low-level: изучить Pin и unsafe; избегать, если можно.
- Любой код, требующий вывода жизни вручную, кастов указателей и множественных мутабельных алиасов — должен быть реализован в unsafe и максимально локализован и покрыт тестами.
Итог (в одну строчку)
- Ownership + borrow checker + lifetimes заставляют явно выражать владение и время жизни, тем самым предотвращая классы ошибок C++ (dangling, data races, double free), но требуют иных идиом: Rc/Arc+(RefCell|Mutex), Weak для циклов, Pin/unsafe для self-referential. Где Rust запрещает паттерн — это обычно потому, что он был бы небезопасен; подобные паттерны возможно реализовать только в unsafe и с дополнительной ответственностью.