Rust on kenji.blog

Объяснение 'владения' и 'заимствования' в Rust в сравнении с указателями C++

Sat, 12 Sep 2026 04:00:00 +0900

В современном системном программировании баланс между производительностью и безопасностью памяти является вечной проблемой. C++ долгие годы господствовал в этой области как король, но в последние годы Rust начинает угрожать его позициям. Главная особенность Rust заключается в концепциях «владения» (Ownership) и «заимствования» (Borrowing), которые гарантируют безопасность памяти во время компиляции без использования сборщика мусора (GC).

В этой статье мы подробно сравним указатели C++ (сырые указатели, std::unique_ptr, std::shared_ptr) с моделью владения Rust, и с помощью примеров кода и диаграмм детально разберем, как компилятор Rust (borrow checker) предотвращает такие ошибки, как использование после освобождения (Use-After-Free) и состояние гонки данных (Data Race).

1. Основы управления памятью: Стек и Куча

Чтобы понять основы управления памятью, давайте сначала вспомним, как программа использует память. Области памяти в основном делятся на «стек» (Stack) и «кучу» (Heap).

Стек (Stack)

Область, куда помещаются локальные переменные при вызовах функций. Она имеет структуру LIFO (последним пришел — первым ушел), и выделение/освобождение памяти происходит очень быстро. Здесь размещаются только те данные, размер которых можно определить во время компиляции.

Куча (Heap)

Здесь размещаются данные, размер которых определяется динамически во время выполнения, а также данные, которые должны существовать за пределами области видимости функции. Доступ к ним осуществляется через указатели (или ссылки).

В языках без сборщика мусора, таких как C++ и Rust, стоимость управления динамической памятью можно смоделировать следующей формулой. Если общее количество объектов равно $N$, среднее время, затрачиваемое на выделение памяти, равно $T_{alloc}$, а среднее время на освобождение — $T_{dealloc}$, то общая стоимость управления памятью $C_{memory}$ составляет:

$$ C_{memory} = \sum_{i=1}^{N} (T_{alloc, i} + T_{dealloc, i}) + O_{sync} $$

Где $O_{sync}$ — это накладные расходы на эксклюзивный контроль (мьютексы или атомарные операции) в многопоточной среде. Поскольку Rust определяет время освобождения памяти на этапе компиляции, он выполняет $T_{dealloc}$ в надежное и безопасное время, сводя к нулю снижение пропускной способности из-за пауз сборщика мусора (Stop-The-World) во время выполнения.

graph TD A["Память программы"] --> B["Стек (Быстрый, фиксированный размер)"] A --> C["Куча (Динамическая, более медленная)"] B --> D["Локальные переменные"] B --> E["Указатели/Ссылки"] C --> F["Динамически выделенные данные"] E -.->|"Указывает на"| F

2. Указатели C++: Компромисс между свободой и опасностью

Давайте рассмотрим эволюцию управления памятью в C++.

Эпоха сырых указателей (Raw Pointers) и их проблемы

Сырые указатели (*), унаследованные от языка C, предоставляют максимальную свободу, но в то же время становятся рассадником следующих серьезных ошибок:

Утечка памяти (Memory Leak): Забытый delete для памяти, выделенной через new.
Висячий указатель (Dangling Pointer): Обращение к указателю после освобождения памяти (после delete).
Двойное освобождение (Double Free): Повторный вызов delete для одной и той же области памяти.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// C++: Пример проблем с сырыми указателями
void rawPointerExample() {
 int* ptr = new int(10);
 // ... какая-то обработка ...
 delete ptr;

 // Ошибочный повторный доступ (Use-After-Free / Dangling Pointer)
 // Компилятор C++ не может выдать ошибку компиляции для этого
 std::cout << *ptr << std::endl; // Неопределенное поведение (Undefined Behavior)
}

Появление RAII и умных указателей (начиная с C++11)

Начиная с C++11, умные указатели, основанные на концепции RAII (Resource Acquisition Is Initialization), были стандартизированы, а прямое использование сырых указателей стало нерекомендованным.

`std::unique_ptr`

Указатель, выражающий уникальное владение. Память автоматически освобождается при выходе из области видимости. Копирование невозможно, возможно только «перемещение» (move) владения (с использованием std::move).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// C++: std::unique_ptr
#include <memory>
#include <iostream>

void uniquePtrExample() {
 std::unique_ptr<int> p1 = std::make_unique<int>(42);
 // std::unique_ptr<int> p2 = p1; // Ошибка компиляции (копирование запрещено)
 std::unique_ptr<int> p3 = std::move(p1); // Перемещение владения

 // Слабое место C++: после перемещения p1 становится nullptr, но сам доступ компилируется
 // Вызывает сбой во время выполнения (ошибка сегментации)
 // std::cout << *p1 << std::endl;
}

`std::shared_ptr`

Указатель, позволяющий нескольким указателям совместно владеть одним и тем же объектом. Он использует подсчет ссылок (Reference Counting) и освобождает память, когда счетчик достигает нуля. Поскольку требуются атомарные операции увеличения/уменьшения, возникают небольшие накладные расходы на производительность (эквивалентные упомянутому ранее $O_{sync}$).

3. Владение (Ownership) в Rust: Смена парадигмы

Rust берет концепцию std::unique_ptr из C++ за основу спецификации языка и обладает еще более строгой «моделью владения».

Три правила владения

Система владения в Rust основана на трех предельно простых правилах:

Каждое значение в Rust имеет переменную, которая называется его владельцем (owner).
В любой момент времени может быть только один владелец.
Когда владелец выходит за пределы области видимости, значение уничтожается.

По умолчанию ресурсы в Rust «перемещаются» (move). Даже без явного указания std::move, как в C++, владение передается при операции присваивания.

1
2
3
4
5
6
7
8


// Rust: Перемещение владения (move)
fn main() {
 let s1 = String::from("hello"); // Данные, выделяемые в куче
 let s2 = s1; // Владение перемещается от s1 к s2

 // Главное отличие от C++: доступ к переменной после перемещения приводит к «ошибке компиляции»!
 // println!("{}, world!", s1); // Ошибка компиляции: value borrowed here after move
}

Именно эта функция, «делающая переменную недоступной на этапе компиляции после перемещения», является одной из причин, почему Rust безопаснее, чем std::unique_ptr в C++.

sequenceDiagram participant S1 as "Переменная s1" participant Heap as "Память в куче ('hello')" participant S2 as "Переменная s2" S1->>Heap: "Выделяет и владеет" Note over S1,S2: "let s2 = s1;" S1--xHeap: "Теряет владение (Инвалидируется)" S2->>Heap: "Принимает владение"

4. Заимствование (Borrowing) и ссылки

Если постоянно передавать владение, то при каждой передаче значения в функцию придется возвращать владение обратно, что крайне неудобно. Для решения этой проблемы появилось «заимствование» (Borrowing). Оно эквивалентно указателям и ссылкам в C++.

В Rust существует два типа заимствования:

Неизменяемая ссылка (Immutable Reference): &T (похоже на const T& в C++)
Изменяемая ссылка (Mutable Reference): &mut T (похоже на T& в C++)

Безжалостные правила Borrow Checker’а

В компилятор Rust встроен «borrow checker» (проверщик заимствований), который проверяет корректность ссылок. Borrow checker принудительно применяет следующие строгие правила:

В любой области видимости может существовать только одно из следующих условий:

Одна изменяемая ссылка (&mut T)

Несколько неизменяемых ссылок (&T)

Это принцип, известный как «Множество читателей ИЛИ Один писатель» (Multiple Readers XOR Single Writer, MRSW). Его можно выразить с помощью математического исключающего ИЛИ (XOR). Для состояния $S$, количество неизменяемых ссылок $N_r$ и изменяемых ссылок $N_w$ должно удовлетворять следующему ограничению:

$$ (N_r \ge 0 \land N_w = 0) \oplus (N_r = 0 \land N_w = 1) $$

Благодаря этому правилу, состояние гонки данных (Data Race) полностью исключается на этапе компиляции. Состояние гонки данных возникает, когда: ① два или более указателя одновременно обращаются к одним и тем же данным, ② по крайней мере один из них выполняет запись, и ③ отсутствует механизм синхронизации. Rust предотвращает состояние гонки данных, разрушая условие ② на этапе компиляции.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// Rust: Ошибка компиляции из-за нарушения правил заимствования
fn main() {
 let mut s = String::from("hello");

 let r1 = &s; // Неизменяемое заимствование (OK)
 let r2 = &s; // Неизменяемое заимствование (OK)
 // let r3 = &mut s; // Ошибка! Нельзя создать изменяемое заимствование, пока существуют неизменяемые

 println!("{}, {}", r1, r2);
}

5. Предотвращение инвалидации итераторов (Iterator Invalidation)

В качестве конкретного примера, демонстрирующего мощь borrow checker’а, давайте рассмотрим классический баг, известный как «инвалидация итератора».

Инвалидация итераторов в C++ (сбой во время выполнения)

Если изменить std::vector в C++ внутри цикла, фоновая память может быть перераспределена (Reallocation), в результате чего ссылки превратятся в висячие указатели.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// C++: Баг инвалидации итератора
#include <iostream>
#include <vector>

int main() {
 std::vector<int> v = {1, 2, 3};

 // Получение ссылки на элемент вектора
 int& first = v[0];

 // Добавление элемента (если емкости недостаточно, выделяется новая область памяти,
 // а старая может быть уничтожена)
 v.push_back(4);

 // first уже может указывать на освобожденную память! (Неопределенное поведение)
 std::cout << "The first element is: " << first << std::endl;

 return 0;
}

Защита на этапе компиляции в Rust

Давайте напишем точно такую же логику на Rust.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// Rust: Предотвращение инвалидации итератора на этапе компиляции
fn main() {
 let mut v = vec![1, 2, 3];

 // Получение неизменяемой ссылки (начало заимствования)
 let first = &v[0];

 // Ошибка! Пока `first` имеет неизменяемое заимствование `v`,
 // невозможно сделать изменяемое заимствование, необходимое для `v.push`.
 // v.push(4);

 println!("The first element is: {}", first);
}

Таким образом, в Rust на уровне компилятора запрещено «изменять значение (делать изменяемое заимствование) во время его чтения (неизменяемого заимствования)». Благодаря этому фатальные баги, такие как Use-After-Free или инвалидация итератора, гарантированно перехватываются на этапе компиляции.

graph LR A["Переменная v (Владелец)"] --> B["Массив в куче [1, 2, 3]"] C["Ссылка 'first' (&v[0])"] -.->|"Неизменяемое заимствование"| B A -->|X "Изменяемое заимствование запрещено!"| D["v.push(4)"] style C stroke:#00FF00,stroke-width:2px style D stroke:#FF0000,stroke-width:2px

6. Совместное владение в Rust: `Rc` и `Arc`

В Rust также предусмотрено совместное владение, эквивалентное std::shared_ptr в C++, но оно четко разделено на типы для однопоточного и многопоточного использования.

Для одного потока: `Rc<T>` (Reference Counted)

Rc<T> — это потоконебезопасный умный указатель с подсчетом ссылок. Поскольку он увеличивает и уменьшает счетчик без использования атомарных инструкций, он очень быстр в рамках одного потока. Однако попытка передать его в другой поток приведет к ошибке компиляции (поскольку он не реализует типаж Send).

Для нескольких потоков: `Arc<T>` (Atomic Reference Counted)

Для совместного использования между потоками применяется Arc<T>, который выполняет атомарные операции. Его накладные расходы сопоставимы с std::shared_ptr из C++.

Кроме того, в C++ при одновременной записи из нескольких потоков в переменную, разделяемую с помощью std::shared_ptr, возникает состояние гонки данных. Чтобы предотвратить это, необходимо правильно вручную использовать std::mutex.

С другой стороны, в Rust невозможно изменить внутренние данные с помощью одного лишь Arc<T>. Если необходимо внести изменения, его нужно комбинировать с мьютексом Mutex<T>.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
 // Комбинация потокобезопасного совместного доступа и эксклюзивного контроля
 // Похоже на std::shared_ptr<std::mutex> в C++, но Mutex инкапсулирует данные
 let counter = Arc::new(Mutex::new(0));
 let mut handles = vec![];

 for _ in 0..10 {
 let counter_clone = Arc::clone(&counter);
 let handle = thread::spawn(move || {
 // Только после вызова lock() мы получаем изменяемую ссылку (&mut i32) на внутренние данные
 let mut num = counter_clone.lock().unwrap();
 *num += 1;
 }); // Освобождение блокировки происходит автоматически при выходе из области видимости благодаря RAII
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }

 println!("Result: {}", *counter.lock().unwrap());
}

Особо стоит отметить, что Mutex<T> в Rust — это не просто механизм блокировки, он «инкапсулирует защищаемые данные как тип». Это позволяет на уровне компиляции полностью предотвратить такую ошибку, как «доступ к данным без предварительной блокировки». Без получения блокировки (lock()) просто невозможно получить права доступа (ссылку) к внутренним данным.

Заключение: «Предварительная проверка» компилятором или «Личная ответственность» разработчика

Указатели и умные указатели в C++ предоставляют разработчикам высокий уровень контроля и производительности, но их правильное использование зависит от дисциплины программиста. Благодаря внедрению RAII и std::unique_ptr, C++ стал значительно безопаснее, однако «неопределенное поведение», такое как доступ после перемещения или инвалидация итераторов, все еще нельзя полностью предотвратить на уровне языка.

В то же время Rust, встраивая в компилятор правила владения (Ownership) и заимствования (Borrowing), обнаруживает подобные ошибки на этапе компиляции, а не во время выполнения. Твердая гарантия того, что «если код компилируется, то он безопасен для памяти», является главной причиной стремительного роста популярности Rust в системном программировании.

«Борьба с borrow checker’ом» (Fight the borrow checker) в Rust становится серьезным препятствием для новичков, но на самом деле это всего лишь процесс, в котором компилятор строго берет на себя сложные вычисления по «отслеживанию времени жизни указателей», которые программисты на C++ обычно делают в уме.

Если вы изучаете Rust, понимая свободу и опасности указателей C++, вы сможете гораздо глубже осознать философию «почему это было спроектировано именно так», лежащую в основе модели владения.

Эта статья представляет собой сравнительное исследование методов управления памятью в C++ и Rust. Надеемся, что она послужит полезным справочным материалом при выборе подходящего языка в зависимости от требований каждого конкретного проекта.

Плюсы и минусы, которые я ощутил, изучая Rust как C++ инженер

Sat, 12 Sep 2026 03:00:00 +0900

Введение: Новый рассвет системного программирования

В современной программной инженерии C++ и Rust являются двумя гигантами, стоящими на передовой системного программирования. На протяжении многих лет C++ безраздельно властвовал в областях, требующих максимальной производительности от аппаратного обеспечения: в операционных системах, встраиваемых устройствах, игровых движках и системах высокочастотного трейдинга (HFT). Я сам, будучи Senior C++ разработчиком, начинал писать код еще в джунглях сырых указателей эпохи C++98, прошел через волну модернизации C++11 (внедрение умных указателей, лямбда-выражений, auto) и продолжал работать бок о бок с непрерывным разрастанием спецификаций в C++14/17/20.

Однако в последние годы Rust продемонстрировал впечатляющий взлет, предлагая решения структурных проблем C++ — в первую очередь, уязвимостей безопасности, вызванных “отсутствием безопасности памяти” (считается, что около 70% CVE связаны с памятью), а также “бесконечно усложняющихся спецификаций и неопределенного поведения (UB)”. Официальное внедрение Rust в ядро Linux и масштабные проекты по переходу на него в таких технологических гигантах, как Microsoft, Google и AWS, — это не просто временное увлечение, а сдвиг парадигмы в системном программировании.

В этой статье я, как истинный C++ инженер, глубоко изучивший Rust и применивший его на практике, подробно сравню и объясню его “плюсы” и “минусы” с технической точки зрения, касающейся самых основ спецификации языка.

1. Сдвиг парадигмы управления памятью: от RAII к владению и заимствованию

RAII в C++ и ограничения умных указателей

Одним из величайших изобретений C++ является RAII (Resource Acquisition Is Initialization). Эта концепция захвата ресурсов в конструкторе и автоматического их освобождения в деструкторе при выходе из области видимости избавила разработчиков от страха утечек памяти, связанных с ручным использованием new и delete. Начиная с C++11, в стандартную библиотеку были добавлены std::unique_ptr и std::shared_ptr, что позволило выразить концепцию владения (Ownership) в коде.

Однако у умных указателей и семантики перемещения в C++ есть фатальный недостаток: статическая проверка компилятором несовершенна.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


#include <iostream>
#include <memory>
#include <string>

void consume(std::unique_ptr<std::string> ptr) {
 std::cout << "Consuming: " << *ptr << std::endl;
}

int main() {
 auto my_ptr = std::make_unique<std::string>("Hello, C++");

 // Передаем владение (перемещение) в функцию
 consume(std::move(my_ptr));

 // ОПАСНОСТЬ: В C++ обращение к объекту после перемещения не вызывает ошибки компиляции
 // std::move — это просто приведение к rvalue-ссылке (T&&), компилятор не блокирует использование
 if (my_ptr) {
 std::cout << "Pointer is still valid?" << std::endl;
 } else {
 std::cout << "Pointer is null." << std::endl;
 }

 // std::cout << *my_ptr << std::endl; // Неопределенное поведение из-за использования после освобождения (Use-After-Free)
 return 0;
}

В C++ всегда существует риск случайного обращения к объекту, опустошенному с помощью std::move (находящемуся в валидном, но неопределенном состоянии). Это может привести к сбоям во время выполнения или, в худшем случае, прямо к уязвимостям безопасности.

Владение (Ownership) в Rust и абсолютная защита Borrow Checker

Rust интегрирует эту концепцию “владения” в самый костяк языка, выполняя строгий статический анализ с помощью функции компилятора, называемой Borrow Checker (Анализатор заимствований).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


fn consume(s: String) {
 println!("Consuming: {}", s);
} // Здесь s выходит из области видимости, и память освобождается (Drop)

fn main() {
 let my_string = String::from("Hello, Rust");

 // Передаем владение (перемещение) в функцию. В Rust семантика перемещения используется по умолчанию.
 consume(my_string);

 // Ошибка компиляции! Обращение к переменной после перемещения абсолютно невозможно
 // println!("Is it still there? {}", my_string);
}

В Rust, как только владение переменной перемещается, компилятор рассматривает исходную переменную как “неинициализированную” и полностью блокирует последующие обращения к ней. Благодаря этому ошибки типа “Use-After-Free” (использование после освобождения) и “Dangling Pointer” (висячий указатель) теоретически не могут пройти компиляцию.

graph TD A["C++ std::unique_ptr"] --> B["Применено std::move"] B --> C["Владение передано"] C --> D["Старый указатель все еще доступен"] D --> E["Потенциальное неопределенное поведение (UB)"] F["Rust Box / String"] --> G["Передано по значению (Move)"] G --> H["Владение передано"] H --> I["Компилятор блокирует старую переменную"] I --> J["Безопасность памяти гарантирована"]

Заимствование (Borrowing) и контроль мутабельности

Еще более мощным инструментом являются правила “Заимствования” (Borrowing) при обращении к ресурсам по ссылке. В Rust соблюдаются следующие строгие правила:

В любой момент времени может существовать только одно из двух: либо “несколько неизменяемых ссылок (&T)”, либо “одна изменяемая ссылка (&mut T)”.
Ссылка не должна жить дольше, чем исходные данные (ограничения времени жизни - Lifetime).

В C++ можно легко создать несколько изменяемых (мутабельных) ссылок или указателей на один и тот же объект, что может привести к неожиданному повреждению состояния (например, инвалидации итераторов). Rust предотвращает подобные ошибки, запрещая комбинацию “алиасинга” (Aliasing) и “мутабельности” (Mutability) на уровне языка.

2. Структура памяти и математические накладные расходы умных указателей

В системном программировании точное понимание структуры памяти (memory layout) абсолютно необходимо. Давайте сравним std::shared_ptr в C++ с std::rc::Rc / std::sync::Arc в Rust.

std::shared_ptr в C++ управляет ресурсами с помощью подсчета ссылок, по умолчанию используя потокобезопасные атомарные операции (std::atomic) для увеличения и уменьшения счетчика. Накладные расходы на память можно формализовать следующим образом:

$$ Overhead_{C++} = sizeof(T) + sizeof(ControlBlock) $$

Здесь $ControlBlock$ содержит “счетчик сильных ссылок (Strong Ref Count)”, “счетчик слабых ссылок (Weak Ref Count)” и “кастомный удалитель (Custom Deleter)”. Проблема заключается в том, что даже при использовании только в одном потоке безоговорочно возникают накладные расходы от атомарных инструкций (блокировка кэш-линий и т.д.).

В отличие от этого, Rust строго разделяет умные указатели в зависимости от их предназначения:

Для одного потока: Rc<T> (Reference Counted)
Для нескольких потоков: Arc<T> (Atomic Reference Counted)

$$ Overhead_{Rc} = sizeof(T) + 2 \times sizeof(usize) $$ $$ Overhead_{Arc} = sizeof(T) + 2 \times sizeof(AtomicUsize) $$

В Rust использование Rc<T>, предназначенного исключительно для одного потока, позволяет полностью избежать штрафов за атомарные вычисления (абстракция с нулевой стоимостью). При этом благодаря механизмам потокобезопасности, описанным ниже, система типов полностью предотвращает случайную передачу Rc<T> в другой поток.

3. Потокобезопасность: Потрясающий “Fearless Concurrency” (Бесстрашная многопоточность)

Многопоточное программирование в C++ всегда шло рука об руку со страхом перед гонками данных (data races) и взаимными блокировками (deadlocks).

Опасность разделения мьютексов и данных в C++

В C++ std::mutex служит исключительно для эксклюзивного контроля над “определенным блоком кода (критической секцией)”, и на уровне языка нет никакой связи между “защищаемыми данными” и самим “мьютексом”.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


#include <iostream>
#include <thread>
#include <mutex>
#include <vector>

std::vector<int> shared_data;
std::mutex mtx;

void worker() {
 // Даже если разработчик забудет захватить блокировку, компиляция пройдет успешно
 // std::lock_guard<std::mutex> lock(mtx);
 shared_data.push_back(1); // Фатальная гонка данных!
}

int main() {
 std::thread t1(worker);
 std::thread t2(worker);
 t1.join();
 t2.join();
 return 0;
}

Mutex в Rust “владеет” данными

В Rust Mutex<T> использует дженерики для инкапсуляции (владения) защищаемыми данными типа T. Чтобы получить доступ к данным, необходимо обязательно вызвать lock() и получить объект-защитник (guard). Синтаксически невозможно обратиться к данным без получения блокировки.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
 // Данные полностью инкапсулированы внутри Mutex
 let shared_data = Arc::new(Mutex::new(Vec::new()));
 let mut handles = vec![];

 for _ in 0..2 {
 // Клонируем Arc (потокобезопасный подсчет ссылок) для совместного использования между потоками
 let data_clone = Arc::clone(&shared_data);
 let handle = thread::spawn(move || {
 // Без получения блокировки невозможно получить доступ к внутреннему Vec
 let mut data = data_clone.lock().unwrap();
 data.push(1);
 });
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }
}

Кроме того, в Rust существуют два основных типажа (traits), гарантирующих безопасность параллельных вычислений:

Send: типы, владение которыми можно безопасно передавать между потоками.
Sync: типы, к которым можно безопасно обращаться одновременно из нескольких потоков.

Например, непотокобезопасный Rc<T> не реализует трейт Send. Поэтому попытка передать его в thread::spawn немедленно вызовет ошибку компиляции. Благодаря этому “Fearless Concurrency” (бесстрашной многопоточности) разработчики избавляются от страха перед багами и могут более агрессивно внедрять распараллеливание.

Согласно закону Амдала (Amdahl’s Law), теоретическая максимальная пропускная способность при доле параллельных вычислений $P$ и степени параллелизма $N$ выражается следующим образом:

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

Rust позволяет предельно безопасно проводить рефакторинг для максимизации $P$, опираясь на систему типов.

graph TD A["Потокобезопасность в C++"] --> B["Опирается на память разработчика"] B --> C["Мьютекс отделен от данных"] C --> D["Высокий риск скрытых гонок данных"] E["Потокобезопасность в Rust"] --> F["Трейты Send и Sync"] F --> G["Мьютекс владеет данными"] G --> H["Гонки данных предотвращаются на этапе компиляции"]

4. Обработка ошибок: Исключения против алгебраических типов данных

Стандартом обработки ошибок в C++ являются “Исключения (Exceptions)”. Однако исключения делают поток управления непрозрачным и вызывают падение производительности (раскрутка стека и раздувание RTTI). Во встраиваемых системах и игровых движках часто прибегают к полному отключению исключений (-fno-exceptions) и использованию классических кодов возврата ошибок. В C++23 был введен std::expected, но его внедрение во всю экосистему займет время.

В Rust концепция исключений отсутствует. Ошибки возвращаются как чистые “значения” и представляются перечислением (алгебраическим типом данных) Result<T, E>.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


use std::fs::File;
use std::io::{self, Read};

// По одному лишь типу возвращаемого значения ясно, что может возникнуть ошибка ввода-вывода (IO error)
fn read_file_content(path: &str) -> Result<String, io::Error> {
 // Оператор ? осуществляет ранний возврат при ошибке, а в случае успеха извлекает содержимое
 let mut file = File::open(path)?;
 let mut content = String::new();
 file.read_to_string(&mut content)?;
 Ok(content)
}

Этот оператор ? поистине революционен. Он устраняет глубокую вложенность (пирамиды из if), возникающую в C++ при проверке кодов ошибок, сохраняя чистый поток управления, подобный исключениям, и при этом явно указывая, при вызове каких функций ошибка передается дальше.

5. Полиморфизм: от виртуальных функций и шаблонов к трейтам

Полиморфизм в C++ реализуется в основном за счет динамической диспетчеризации через наследование классов и виртуальные функции (virtual), либо статической диспетчеризации через шаблоны (например, CRTP).

При динамической диспетчеризации в объект встраивается указатель (vptr) на таблицу виртуальных функций (vtable), что создает накладные расходы на разрешение указателя во время вызова функции.

$$ T_{dispatch} = T_{lookup\_in\_vtable} + T_{dereference} $$

Rust отказался от классического объектно-ориентированного “наследования классов” в пользу концепции “Трейтов (Traits)” (похоже на Concepts в C++20, но более функционально).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


trait Drawable {
 fn draw(&self);
}

struct Circle { radius: f64 }
impl Drawable for Circle {
 fn draw(&self) { println!("Drawing a Circle of radius {}", self.radius); }
}

// Статическая диспетчеризация (мономорфизация, нулевые накладные расходы)
fn draw_static<T: Drawable>(item: &T) {
 item.draw();
}

// Динамическая диспетчеризация (трейт-объект)
fn draw_dynamic(item: &dyn Drawable) {
 item.draw();
}

Главная особенность динамической диспетчеризации в Rust (dyn Trait) заключается в том, что вместо хранения vptr внутри структуры данных используются Толстые указатели (Fat Pointers). Толстый указатель содержит пару: “указатель на данные” и “указатель на vtable”. Это значительно упрощает реализацию (расширение) трейтов для типов, определенных во внешних библиотеках, с последующим использованием динамической диспетчеризации.

6. Управление пакетами и системы сборки: страдания с CMake и блага Cargo

Одна из главных слабостей C++ — отсутствие стандартного пакетного менеджера. Запутанный синтаксис CMakeLists.txt, сложность разрешения зависимостей через find_package и различия в путях к библиотекам в зависимости от ОС постоянно отнимают огромное количество времени у C++ инженеров.

В Rust по умолчанию включен Cargo — один из лучших в мире менеджеров пакетов и систем сборки.

graph TD A["Среда сборки C++"] --> B["CMakeLists.txt"] B --> C["Интеграция vcpkg / Conan"] C --> D["Генерация Makefiles / Ninja"] D --> E["Компилятор (GCC/Clang/MSVC)"] F["Среда сборки Rust"] --> G["Cargo.toml"] G --> H["Получение зависимостей из crates.io"] H --> I["rustc (Cargo build)"] I --> J["Готовый к запуску бинарный файл"]

Достаточно добавить всего одну строку с названием и версией библиотеки (крейта) в Cargo.toml, и транзитивное разрешение зависимостей, скачивание и сборка произойдут полностью автоматически. Более того, весь необходимый инструментарий для разработки — тестирование (cargo test), генерация документации (cargo doc), статический анализ (cargo clippy), форматирование (cargo fmt) — объединен в одной этой команде. Этот уровень комфорта обладает настолько разрушительной силой, что, познав его однажды, вам больше не захочется возвращаться к среде сборки C++.

7. Минусы и кривая обучения при изучении Rust

До сих пор я говорил о достоинствах Rust, но, безусловно, существуют “барьеры” и недостатки, с которыми столкнется C++ инженер при внедрении Rust в реальные проекты.

1. Ожесточенная борьба с Borrow Checker

Если вы попытаетесь в лоб реализовать на Rust структуры данных, которые в C++ вы “как-то связывали сырыми указателями” (например, двусвязные списки, графы или самоссылающиеся структуры), код не скомпилируется из-за ограничений владения и времени жизни. Чтобы удовлетворить Borrow Checker, придется либо использовать сложные обертки вроде Rc<RefCell<T>>, либо радикально пересмотреть архитектуру в пользу аренных аллокаторов или управления на основе индексов.

2. Длительное время компиляции

Компиляция C++ также замедляется из-за вложенности шаблонов, но и в Rust время компиляции (особенно чистой сборки с нуля) отнюдь не маленькое. Мощные проходы оптимизации LLVM, раскрытие макросов и мономорфизация дженериков накладываются друг на друга, превращая время сборки в узкое место в крупных проектах. Во время разработки необходимо прибегать к хитростям вроде частого использования cargo check.

3. Взаимодействие с кодовыми базами на C++

Взаимодействие с языком C (FFI) проходит очень гладко, однако прямая интеграция Rust с существующими гигантскими кодовыми базами C++ (активно использующими классы, шаблоны и виртуальные функции) крайне сложна. Хотя в последние годы такие инструменты-мосты, как cxx и autocxx, сильно эволюционировали, до полностью бесшовного перехода еще очень далеко.

Заключение: Стоит ли нам переходить на Rust?

C++ продолжит играть важную роль в разработке игровых движков и огромных существующих инфраструктурах. Модернизация благодаря C++20/23 также впечатляет, и писать безопасный код становится проще.

Однако при “создании новых проектов в области системного программирования” мне теперь гораздо сложнее найти причины НЕ выбирать Rust. “Надежность” Rust — тот факт, что успешная компиляция освобождает от страха неопределенного поведения и повреждения памяти, позволяя безопасно выполнять параллельную обработку с высокой производительностью — радикально улучшает ментальную модель инженера.

Для C++ инженеров изучение Rust — это не просто запоминание нового синтаксиса, а лучший опыт обретения новой перспективы на “безопасные методы управления памятью и потоками”. Обязательно попробуйте сами ощутить комфорт Cargo и строгость Borrow Checker.