Lifetime и destructors: когда вызывается деструктор

1. Время жизни и деструктор: базовая идея

Когда вы только начинаете, кажется, что программа — это просто последовательность строк, а переменные — это «ячейки», которые живут где-то «пока не надоест». Но C++ — язык строгий: у любого объекта есть время жизни (lifetime). И когда оно заканчивается, язык обязан (в нормальных сценариях завершения) выполнить специальные действия: вызвать деструктор.

Почему это важно на практике? Потому что почти все удобства стандартной библиотеки построены на этом: строки освобождают буфер, векторы освобождают память под элементы, файлы закрываются (это будет позже), и даже ваши собственные типы могут «убираться за собой». В стандарте C++ тема времени жизни объектов выделена как отдельная важная часть (часто обсуждается в контексте [basic.life]).

Lifetime: где он начинается и где заканчивается

Если говорить по-человечески, lifetime объекта — это интервал от момента, когда объект создан, до момента, когда он уничтожен. Здесь полезно разделить две похожие, но разные идеи: scope (где видно имя) и lifetime (существует ли объект). Чаще всего у локальных переменных эти две вещи совпадают: вошли в блок — объект появился, вышли из блока — объект исчез.

Важно уловить интуицию: «последний раз я использовал переменную» не является сигналом для C++. Компилятор не думает: «О, Вася больше не читает s, давайте сотрем s прямо сейчас». Он думает проще: «Локальный объект живёт до конца блока, точка».

Ниже — маленькая «карта времени жизни» для локального объекта:

flowchart LR
    A["Вход в блок {"] --> B["Создание объекта (инициализация)"]
    B --> C["Использование объекта"]
    C --> D["Выход из блока }"]
    D --> E["Вызов деструктора ~Type()"]

Деструктор: что это за функция и почему она вызывается «сама»

Деструктор — это специальная функция вида ~Type(), которую C++ вызывает автоматически, когда заканчивается lifetime объекта. Даже если вы сами деструктор не писали, он обычно существует «по умолчанию»: компилятор может сгенерировать его за вас (пока мы не углубляемся в правила генерации, нам достаточно факта: у объекта есть механизм уничтожения).

Главная мысль этой лекции: вызов деструктора привязан к окончанию времени жизни, а не к вашей команде “уничтожься”. Поэтому новичкам полезно один раз увидеть это глазами — мы сейчас сделаем тип, который печатает сообщения при создании и уничтожении.

#include <iostream>
#include <string>

struct Tracer {
    std::string name;

    Tracer(const std::string& n) : name(n) {
        std::cout << "create " << name << '\n';
    }
    ~Tracer() {
        std::cout << "destroy " << name << '\n';
    }
};

int main() {
    Tracer t("X");
    std::cout << "inside main\n";
}
// create X
// inside main
// destroy X

Заметьте характерную вещь: destroy X печатается в самом конце, на выходе из main. Мы нигде не писали «вызови деструктор» — он вызвался автоматически.

2. Локальные объекты и выход из scope

Локальные объекты: деструктор вызывается на }

Локальные переменные внутри функций и блоков {} обычно имеют automatic storage duration. Это означает: объект создаётся при входе в блок и уничтожается при выходе. Для таких объектов ответ «когда вызывается деструктор?» почти всегда звучит так: на закрывающей фигурной скобке.

Проверим это на вложенном блоке. Это очень хороший приём, чтобы сознательно сократить lifetime «тяжёлого» объекта: создали — использовали — и как можно раньше уничтожили, не дожидаясь конца функции.

#include <iostream>
#include <string>

struct Tracer {
    std::string name;
    Tracer(const std::string& n) : name(n) { std::cout << "create " << name << '\n'; }
    ~Tracer() { std::cout << "destroy " << name << '\n'; }
};

int main() {
    std::cout << "A\n";
    { Tracer t("inner"); std::cout << "B\n"; }
    std::cout << "C\n";
}
// A
// create inner
// B
// destroy inner
// C

Смотрите на порядок: destroy inner печатается между "B" и "C", потому что мы вышли из блока. Это и есть практическое ощущение: «деструктор на }».

Ранний выход: return тоже завершает lifetime

Очень частая ошибка новичка — думать, что return «выпрыгивает» из функции как телепорт и «пропускает уборку». В реальности return просто означает: «мы покидаем scope функции». А раз покидаем scope — значит все локальные automatic-объекты должны быть корректно уничтожены, и их деструкторы должны быть вызваны.

Это критично для нормального C++: иначе std::string, std::vector и половина стандартной библиотеки были бы бесполезны (память бы “убегала” при каждом раннем выходе).

#include <iostream>
#include <string>

struct Tracer {
    std::string name;
    Tracer(const std::string& n) : name(n) { std::cout << "create " << name << '\n'; }
    ~Tracer() { std::cout << "destroy " << name << '\n'; }
};

void f(bool early) {
    Tracer t("in f");
    if (early) return;
    std::cout << "doing work\n";
}

int main() {
    f(true);
    f(false);
}
// create in f
// destroy in f
// create in f
// doing work
// destroy in f

Обратите внимание: деструктор destroy in f вызывается в обоих случаях. Просто в первом случае — раньше.

Порядок уничтожения: последним объявил — первым уничтожился

Теперь давайте добавим ещё одну деталь, которая часто всплывает в неожиданных багах: порядок разрушения объектов в одном scope обратный порядку их объявления. Это очень похоже на стек: последнее положили — первое достали. Такой порядок позволяет корректно разрушать «зависимости» (условно: сначала закрыть то, что использует другое).

Увидим это в лоб:

#include <iostream>
#include <string>

struct Tracer {
    std::string name;
    Tracer(const std::string& n) : name(n) { std::cout << "create " << name << '\n'; }
    ~Tracer() { std::cout << "destroy " << name << '\n'; }
};

int main() {
    Tracer a("A");
    Tracer b("B");
    std::cout << "end\n";
}
// create A
// create B
// end
// destroy B
// destroy A

Запомните простое правило: в одном блоке уничтожение идёт снизу вверх (в обратном порядке объявления). Это потом поможет вам понимать неожиданные сообщения в логах и поведение более сложных объектов.

3. Составные объекты и контейнеры

Поля struct тоже уничтожаются и тоже в обратном порядке

Когда у вас есть struct с полями, поля — это тоже объекты. И у них тоже есть lifetime. Когда заканчивается lifetime внешнего объекта, C++ должен разрушить и его поля.

Чтобы почувствовать идею без перегруза теорией, сделаем struct, который содержит два Tracer-поля:

#include <iostream>
#include <string>

struct Tracer {
    std::string name;
    Tracer(const std::string& n) : name(n) { std::cout << "create " << name << '\n'; }
    ~Tracer() { std::cout << "destroy " << name << '\n'; }
};

struct Box {
    Tracer first{"first"};
    Tracer second{"second"};
};

int main() {
    Box b;
    std::cout << "done\n";
}
// create first
// create second
// done
// destroy second
// destroy first

Здесь мы снова видим «обратный порядок» — но уже для полей: second уничтожился раньше first. Это ожидаемо: уничтожение полей идёт в обратном порядке их объявления в struct.

Контейнеры: деструктор освобождает ресурсы и уничтожает элементы

Сейчас будет важный момент, который связывает сегодняшнюю лекцию с тем, что вы уже знаете про std::vector и std::string. Контейнеры — это владельцы ресурсов. Вектор владеет памятью под элементы. Строка владеет буфером символов. И когда заканчивается lifetime контейнера, вызывается его деструктор — а значит контейнер должен корректно освободить свои ресурсы.

На нашем уровне достаточно понимать это так: если std::vector<Tracer> является локальным объектом, то на выходе из scope уничтожится сам vector, а затем он уничтожит свои элементы (и вызовет их деструкторы). То есть ваши Tracer внутри вектора тоже «уберутся».

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

struct Tracer {
    std::string name;
    Tracer(const std::string& n) : name(n) { std::cout << "create " << name << '\n'; }
    ~Tracer() { std::cout << "destroy " << name << '\n'; }
};

int main() {
    std::vector<Tracer> v;
    v.push_back(Tracer("one"));
    v.push_back(Tracer("two"));
    std::cout << "leaving scope\n";
}
// (сообщения create/destroy зависят от оптимизаций, но в конце scope элементы будут уничтожены)

Важная оговорка: точные промежуточные сообщения (особенно «лишние» создания/уничтожения временных объектов) могут отличаться из-за оптимизаций и деталей добавления в вектор. Но ключевой факт остаётся: когда вектор умирает, его элементы тоже умирают.

Ещё одна практическая грань: элементы могут уничтожаться и раньше, если вы делаете clear(), erase() или resize() в меньшую сторону. Но базовая “опорная точка” для новичка — именно деструктор контейнера на выходе из scope.

4. Долгоживущие объекты и отладка scope

static объекты: живут долго и уничтожаются в конце программы

Теперь — про «долгоиграющие» объекты. Если объект имеет static storage duration, то в упрощённой модели он живёт всю программу: создаётся один раз и уничтожается при завершении программы. Это относится к глобальным объектам и к static локальным переменным внутри функции.

С точки зрения вопроса лекции («когда реально вызывается деструктор?») ответ: обычно в самом конце работы программы, когда она завершается штатно.

Покажем static локальный объект, который создаётся один раз и переживает несколько вызовов функции:

#include <iostream>
#include <string>

struct Tracer {
    std::string name;
    Tracer(const std::string& n) : name(n) { std::cout << "create " << name << '\n'; }
    ~Tracer() { std::cout << "destroy " << name << '\n'; }
};

void hits() {
    static Tracer t("static-in-hits");
    std::cout << "hits()\n";
}

int main() {
    hits();
    hits();
    std::cout << "main ends\n";
}
// create static-in-hits
// hits()
// hits()
// main ends
// destroy static-in-hits

Практический вывод: static — это не «магическая память», это просто другой режим времени жизни. Он удобен, но требует аккуратности: объект живёт долго, и если в нём хранится состояние, оно тоже живёт долго.

Мини-инструмент: логер выхода из scope

Сейчас сделаем штуку, которую вы будете любить (и иногда ненавидеть) при отладке: объект, который печатает сообщение при входе в функцию и при выходе из неё. Это классический трюк: мы используем тот факт, что деструктор вызывается автоматически на выходе из scope, и превращаем его в «событие выхода».

Представим, что мы продолжаем наше консольное мини-приложение (условно, список задач), где функции делают понятные шаги: добавить задачу, показать задачи, посчитать статистику. Добавим “охранника scope”:

#include <iostream>
#include <string>

struct ScopeLog {
    std::string name;

    ScopeLog(const std::string& n) : name(n) {
        std::cout << ">> enter " << name << '\n';
    }
    ~ScopeLog() {
        std::cout << "<< leave " << name << '\n';
    }
};

void print_tasks() {
    ScopeLog log("print_tasks");
    std::cout << "printing...\n";
}

int main() {
    print_tasks();
}
// >> enter print_tasks
// printing...
// << leave print_tasks

Теперь важная мысль: мы ничего не “вызываем вручную” для << leave. Он печатается сам, потому что log — локальный объект, и на выходе из print_tasks() заканчивается его lifetime.

Это отличный способ «поймать» моменты, когда вы неожиданно выходите из функции раньше (например, из-за return), и понять, какие участки кода реально выполняются.

5. Типичные ошибки

Ошибка №1: ожидать, что объект уничтожится “сразу после последнего использования”.
Новичок часто смотрит на код глазами человека: «ну я же больше не обращаюсь к s после этой строки, значит s должен умереть». В C++ так думать опасно: деструктор для локального объекта обычно вызывается на границе scope, то есть на }. Если нужно ограничить время жизни раньше — делайте вложенный блок и создавайте объект внутри него.

Ошибка №2: путать “имя не видно” и “объекта не существует”.
Бывает обратная путаница: студент уверен, что раз переменную не видно из текущей строки, то она уже уничтожена. На самом деле “не видно” означает только то, что имя вне scope. Существует ли объект — это вопрос lifetime, и он чаще всего привязан к конкретному блоку и его границам.

Ошибка №3: не учитывать обратный порядок разрушения и удивляться логам.
Когда вы видите destroy B, а потом destroy A, первая реакция бывает: «компьютер перепутал». Он не перепутал: в одном scope уничтожение идёт в обратном порядке объявления. Если ваши объекты логически зависят друг от друга, порядок объявления становится важным, потому что на выходе из scope «разборка» пойдёт в обратном порядке.

Ошибка №4: думать, что static ведёт себя “как обычная локальная переменная”.
static локальная переменная выглядит как локальная, но живёт как глобальная: создаётся один раз и уничтожается в конце программы. Это легко превращается в “скрытое состояние”, которое неожиданно влияет на поведение функции при повторных вызовах. Если вы используете static, держите в голове: это решение про долгую жизнь объекта.

Ошибка №5: считать, что контейнер “сам всё очистит, когда я перестану им пользоваться”, но забывать про scope.
Да, std::vector и std::string корректно освобождают ресурсы в деструкторе. Но деструктор вызовется только тогда, когда закончится lifetime контейнера. Если вы держите контейнер слишком долго (например, объявили его слишком высоко в функции), память тоже будет удерживаться дольше. Это не баг контейнера — это ваш выбор времени жизни.