Привет, Хабр!

C++ остаётся языком, в котором ошибки с памятью продолжают валить программы в самых неожиданных местах: программа стартует, работает на тестовых данных, на боевых через час падает с Segmentation fault, отладчик показывает падение в недрах стандартной библиотеки, и непонятно даже, куда смотреть.

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

У начинающих эта модель часто не сложена, и одни и те же пять‑шесть ошибок повторяются из проекта в проект.

Разберём пять самых частых:

  1. возврат ссылок на локальные переменные;

  2. забытый delete;

  3. обращение к объекту после std::move;

  4. выход за границы массива;

  5. двойное удаление.

Возврат ссылки или указателя на локальную переменную

Соблазнительная конструкция, которую новички пишут постоянно:

#include <iostream>
#include <string>

const std::string& get_greeting(const std::string& name) {
    std::string result = "Hello, " + name + "!";
    return result;
}

int main() {
    const std::string& greeting = get_greeting("World");
    std::cout << greeting << '\n';
}

Программа компилируется, иногда даже выводит «Hello, World!», и кажется, что всё работает. В реальности это undefined behavior. Переменная result живёт в стек‑фрейме функции get_greeting. Когда функция завершается, её стек‑фрейм перестаёт существовать. Ссылка, которую вернула функция, указывает на память, в которой раньше лежала result, и эта память может быть использована любым следующим вызовом функции.

В debug‑сборке часто получается «правильный» вывод просто потому, что компилятор не оптимизирует, и память пока не переиспользована. В release‑сборке программа может выдавать мусор, может крашиться, может работать в одной сборке и падать в другой при добавлении нового кода. Это самый неприятненький класс ошибок, потому что он непредсказуем.

GCC и Clang с флагом -Wreturn-local-addr (включён в -Wall) выдают предупреждение для прямого возврата ссылки на локальную переменную. Visual Studio Compiler делает то же самое через C4172. Но если возврат происходит через цепочку вызовов, статический анализатор часто не справляется, и предупреждения нет.

Правильное решение зависит от того, что должна делать функция. Если результат — это только что созданная строка, возвращайте по значению:

std::string get_greeting(const std::string& name) {
    return "Hello, " + name + "!";
}

Современный компилятор применяет return value optimization, и копирование при возврате не происходит. Объект сразу конструируется в памяти вызывающей стороны. Это работает с C++17 для большинства случаев и было обязательным для prvalue с того же стандарта.

Если результат — это ссылка на существующий объект (например, элемент контейнера, поле класса), возврат по ссылке корректен, но нужно следить, чтобы возвращаемый объект жил дольше, чем вызывающий код будет использовать ссылку.

class Cache {
public:
    const std::string& get_value(const std::string& key) const {
        return values_.at(key);  // ссылка на элемент map, живёт пока живёт map
    }
private:
    std::map<std::string, std::string> values_;
};

Тут ссылка указывает на элемент values_, который живёт пока живёт сам объект Cache. Это нормально.

Утечка памяти через new без delete

Классический пример первой программы с динамической памятью:

#include <iostream>

int main() {
    int* numbers = new int[1000000];
    
    for (int i = 0; i < 1000000; ++i) {
        numbers[i] = i;
    }
    
    std::cout << "Sum: " << numbers[999999] << '\n';
    return 0;
}

Программа отрабатывает, выводит результат, выходит. Память освобождает операционная система при завершении процесса. Кажется, что всё нормально. Проблема становится видимой, когда такой код запускается не один раз, а тысячи: в цикле обработки сообщений, в callback‑функции, в обработчике HTTP‑запросов. Каждое выделение new без delete оставляет блок памяти, который не освобождается до конца жизни процесса.

Через час работы сервиса процесс съедает несколько гигабайт памяти, контейнерный orchestrator его убивает по OOMKilled, alert летит на дежурного. После расследования обнаруживается: где‑то в обработчике висит new без парного delete.

Усугубляет проблему то, что забыть delete легко. Например, исключение между new и delete пропускает освобождение:

void process_data() {
    int* buffer = new int[1000];
    
    fill_buffer(buffer);  // если эта функция бросит, delete никогда не выполнится
    do_work(buffer);
    
    delete[] buffer;
}

Современный C++ решает проблему через идиому RAII: ресурсы (память, файлы, мьютексы) привязываются к жизненному циклу объектов на стеке, и их освобождение происходит автоматически в деструкторе.

Для динамических массивов используется std::vector:

#include <iostream>
#include <vector>

int main() {
    std::vector<int> numbers(1000000);
    
    for (int i = 0; i < 1000000; ++i) {
        numbers[i] = i;
    }
    
    std::cout << "Sum: " << numbers[999999] << '\n';
}

Память выделяется внутри vector, освобождается автоматически при выходе из main. Если возникает исключение внутри функции, деструктор vector всё равно вызывается, и память освобождается.

Для единичных динамических объектов используется std::unique_ptr или std::shared_ptr:

#include <memory>

void process() {
    auto resource = std::make_unique<HeavyObject>();
    resource->do_work();
    // delete не нужен, unique_ptr сам освободит память в деструкторе
}

В современном C++ коде вызов new встречается редко, обычно глубоко внутри библиотечного кода. Прямой new в пользовательском коде — это плохой знак, повод задуматься, нельзя ли заменить на RAII‑обёртку.

Использование объекта после std::move

Move‑семантика появилась в C++11 и стала повсеместной. Когда новички начинают пользоваться std::move, появляется типичная ошибка:

#include <iostream>
#include <string>
#include <vector>

void process_message(std::string message) {
    // ...
}

int main() {
    std::string greeting = "Hello, world!";
    process_message(std::move(greeting));
    
    std::cout << "Length of greeting: " << greeting.length() << '\n';
    std::cout << "Greeting: " << greeting << '\n';
}

Программа компилируется без предупреждений. Запускается, выдаёт обычно «Length of greeting: 0» и пустую строку во второй вывод. Технически это не undefined behavior: после std::move объект находится в валидном, но неопределённом состоянии. Какой именно объект там окажется, зависит от реализации стандартной библиотеки и от типа.

Для std::string обычно это пустая строка. Для std::vector обычно это пустой вектор. Для произвольного пользовательского типа поведение зависит от того, как написан move‑конструктор и move‑оператор присваивания. Полагаться на конкретные значения после move нельзя.

Распространённое заблуждение: «после std::move объект остаётся прежним, std::move это просто приведение типа». На уровне языка это так: std::move это static_cast к rvalue reference. Но в момент вызова move‑конструктора или move‑assignment объект‑источник передаёт своё содержимое получателю и остаётся в состоянии, готовом к уничтожению.

Правильная идиома: после std::move относитесь к объекту так, как будто он только что был создан конструктором по умолчанию. Можно ему присвоить новое значение, можно уничтожить, можно вызвать методы, которые работают на пустом состоянии. Читать содержимое нельзя, если только вы не уверены в семантике конкретного типа.

#include <iostream>
#include <string>

int main() {
    std::string greeting = "Hello, world!";
    process_message(std::move(greeting));
    
    // greeting сейчас в каком-то неопределённом состоянии, перед использованием задаём заново
    greeting = "Welcome!";
    std::cout << "Greeting: " << greeting << '\n';
}

Современные статические анализаторы (clang‑tidy с проверкой bugprone-use-after-move, MSVC analyzer) находят такие ошибки и выдают предупреждение. Включить эти проверки в CI стоит сразу, как только в проекте появляется хоть один std::move.

Выход за границы массива

В C++ нет проверок границ для встроенных массивов и сырых указателей. Вы можете обратиться к arr[100] для массива размером 10, и компилятор не возразит:

#include <iostream>

int main() {
    int numbers[10];
    
    for (int i = 0; i <= 10; ++i) {
        numbers[i] = i * 2;
    }
    
    std::cout << "Done\n";
}

Цикл i <= 10 это классическая off‑by‑one ошибка. Десятый элемент (с индексом 10) не входит в массив, его максимальный индекс 9. Запись в numbers[10] обращается к памяти за пределами массива. Иногда там лежит другая переменная функции (тогда программа выдаёт неожиданные результаты), иногда служебные данные стека (тогда программа крашится при возврате из функции), иногда никем не используемая память (тогда программа отрабатывает корректно и ошибка прячется до момента, когда расположение объектов в памяти изменится из‑за оптимизатора).

Программа может работать годами, проходить все тесты, а потом упасть в проде после обновления компилятора или добавления безобидной фичи, потому что расположение объектов в памяти изменилось.

Решений несколько.

Первое, и самое идиоматичное: использовать std::vector вместо встроенных массивов и пользоваться .at(index), который проверяет границы и бросает std::out_of_range при выходе:

#include <iostream>
#include <vector>

int main() {
    std::vector<int> numbers(10);
    
    try {
        for (size_t i = 0; i <= 10; ++i) {
            numbers.at(i) = i * 2;
        }
    } catch (const std::out_of_range& e) {
        std::cout << "Error: " << e.what() << '\n';
    }
}

Программа выведет понятное сообщение об ошибке вместо краша или непредсказуемого поведения. Минус at() в небольшом оверхеде на проверку, но в большинстве случаев он не заметен.

Второе решение: использовать range‑based for, который работает с контейнерами без явных индексов и не позволяет выйти за границы:

int index = 0;
for (auto& number : numbers) {
    number = index++ * 2;
}

Третье решение, доступное с C++20: std::span, который оборачивает массив или часть массива и при использовании .at() тоже проверяет границы. Полезен в функциях, принимающих массивы как параметры, чтобы избежать передачи указателя и размера отдельно.

AddressSanitizer ловит выход за границы массива в runtime в 100% случаев. Включать его в CI обязательно для любого C++ проекта. Запуск тестов под санитайзером занимает в полтора‑два раза дольше, но окупается на первой же найденной ошибке.

Двойное удаление одной и той же памяти

Сценарий с менеджером ресурсов:

#include <iostream>

class ResourceManager {
public:
    ResourceManager(int size) {
        buffer_ = new int[size];
        size_ = size;
    }
    
    ~ResourceManager() {
        delete[] buffer_;
    }
    
private:
    int* buffer_;
    int size_;
};

void process() {
    ResourceManager rm(1000);
    ResourceManager copy = rm;  // копирование!
}

Программа создаёт объект rm, потом копирует его в copy. Поскольку в классе нет явного copy‑конструктора, компилятор создаёт его автоматически, и этот автоматический конструктор просто копирует поля по членам. Указатель buffer_ копируется как значение, и теперь у rm и copy один и тот же указатель на одну и ту же память.

При выходе из process сначала вызывается деструктор copy, который освобождает память. Потом вызывается деструктор rm, который пытается освободить ту же память ещё раз. Двойной delete[] это undefined behavior, обычно проявляющийся крашем или, что хуже, повреждением кучи. Повреждённая куча приводит к падению через произвольное время в случайной точке кода, и связать симптом с причиной может быть невероятно сложно.

Эта проблема решается следованием «Правилу трёх» (или «Правилу пяти» с C++11): если класс управляет ресурсом и в нём есть деструктор, который этот ресурс освобождает, нужно либо явно определить copy‑конструктор и copy‑assignment (и move‑варианты в C++11+), либо запретить копирование.

Современная идиома: использовать smart pointers и стандартные контейнеры, которые уже правильно реализуют все необходимые методы:

#include <vector>
#include <memory>

class ResourceManager {
public:
    ResourceManager(int size) : buffer_(size) {}
    
private:
    std::vector<int> buffer_;
};

Деструктор не нужен, потому что std::vector сам освобождает память. Copy и move работают корректно: vector при копировании выделяет новую память и копирует содержимое, при перемещении передаёт указатель без копирования. Двойного удаления не происходит никогда.

Альтернатива через std::unique_ptr для случаев, когда нужен именно динамически выделенный объект:

class ResourceManager {
public:
    ResourceManager(int size) : buffer_(std::make_unique<int[]>(size)) {}
    
private:
    std::unique_ptr<int[]> buffer_;
};

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

Правило идиоматичного C++: класс, который вы пишете, либо вообще не управляет ресурсами (тогда дефолтные методы компилятора работают правильно), либо управляет одним ресурсом через готовую обёртку (vector, unique_ptr, string), либо явно реализует все необходимые методы (copy, move, destructor) с учётом семантики ресурса.

Современный C++ почти всё это уже решает на уровне языка и стандартной библиотеки. Возврат по значению с RVO заменяет возврат ссылок на локальные объекты. std::vector и std::unique_ptr заменяют ручное управление памятью через new и delete. Range‑based for и контейнеры с проверкой границ убирают возможность off‑by‑one. Smart pointers и контейнеры стандартной библиотеки реализуют правильное copy/move поведение, и писать собственные деструкторы становится не нужно.

К идиомам стоит добавить инструменты в CI: AddressSanitizer и UndefinedBehaviorSanitizer ловят почти все ошибки с памятью автоматически на первом же тесте, clang‑tidy с наборами bugprone и cppcoreguidelines подсвечивает потенциально опасные паттерны до запуска кода, valgrind помогает в сложных случаях.

А вы какие проверки крутите на своих C++‑проектах? Подключаете санитайзеры на каждом PR или гоняете только в nightly?

Читайте больше о разработке на C++ в материале «Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт».

Хотите меньше крашей, утечек памяти и сюрпризов от new/delete в C++? Присмотритесь к открытым урокам: на них преподаватели‑практики покажут, как надёжнее работать с ресурсами, проектировать C++‑код и не превращать поддержку приложения в археологию.

  • 30 июня в 20:00 — «RAII в C++: фундамент надёжного управления ресурсами». Записаться
    Как управлять памятью без утечек и ручного delete.

  • 14 июля в 20:00 — «Как разрабатывать пользовательские интерфейсы на C++». Записаться
    Создание UI-элементов без громоздких фреймворков.

  • 22 июля в 20:00 — «Архитектура программ на C++: как управлять разработкой и функциями приложения». Записаться
    Подходы к коду, который проще развивать и поддерживать.

Больше бесплатных уроков июня смотрите в дайджесте.