Что делает дебаггер: останов и пошаговое выполнение

1. Зачем нужен дебаггер

Когда программа ведёт себя странно, у новичка обычно два инструмента: паника и std::cout << "Я тут!\n";. Паника бесполезна, а cout — полезен, но иногда превращает код в новогоднюю гирлянду из принтов. Дебаггер — это инструмент, который позволяет остановить программу во время выполнения и спокойно посмотреть: «Что у меня в переменных? Какой путь по if реально выбран? Почему цикл не заканчивается?».

Дебаггер нужен, потому что большинство багов — это не «компилятор сломался», а одно из трёх:

1. программа выполняется не так, как вы думаете;
2. данные внутри программы не такие, как вы думаете;
3. программа вообще не выполняется (ждёт ввод, ушла в вечный цикл, упала и т.д.).

Печать (std::cout) показывает вам «что-то» уже после того, как вы вставили печать, пересобрали проект, запустили и поймали момент. Дебаггер показывает вам состояние прямо сейчас, причём вы можете «прокрутить» выполнение вперёд по шагам.

Для ментальной модели держим простую мысль: «std::cout — это “я оставил записку самому себе”, а дебаггер — это “я остановил время и залез в голову программе”».

2. Что делает дебаггер в отладочной сессии

Представьте, что ваша программа — это поезд, который едет по рельсам исходного кода. Обычно вы нажимаете Run — и поезд «пролетает» от main() до конца, а вы видите только финальные станции (вывод в консоль, результат, падение).

Дебаггер делает другое: он запускает тот же поезд, но даёт вам пульт управления. Вы можете:

• остановить поезд;
• продолжить движение;
• сделать один «шаг» вперёд;
• посмотреть на “груз” (значения переменных).

Очень важно понять один принцип: дебаггер управляет выполняемым файлом (бинарником), а не «текстом кода». Текст — это карта, а едет поезд по реальным рельсам — машинным инструкциям. Чтобы карта совпадала с рельсами, нужны специальные «подсказки» — отладочные символы (об этом ниже).

Вот простая схема того, что происходит:

flowchart LR
    A["Исходный код (.cpp)"] --> B["Компиляция (Debug)"]
    B --> C["Бинарник + отладочные символы"]
    C --> D["Запуск под дебаггером"]
    D --> E["Останов / просмотр переменных / шаги"]

Слово сессия (debug session) означает: запуск программы под контролем дебаггера. Это именно запуск, просто с надстройкой управления.

3. Что значит «программа остановлена»

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

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

То есть вы смотрите на точку во времени «за миллисекунду до».

Откуда берётся останов

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

• вы вручную нажали Pause (пауза);
• вы запускаете отладку «со старта» и IDE останавливается в начале main() (некоторые IDE так умеют);
• программа дошла до заранее отмеченного места (обычно это breakpoint);
• программа завершилась (дебаггер просто сообщает «всё»);
• программа аварийно упала (деление на ноль, выход за границы, и т.п.);
• программа «зависла» — а на деле ждёт ввод (это отдельный суперчастый случай).

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

4. Пошаговое выполнение

Если вы когда-то ставили видео на паузу и листали кадр за кадром, то вы почти уже умеете «step». Пошаговое выполнение — это выполнение программы небольшими порциями, чтобы увидеть: какая строка выполнилась, и как изменились значения.

В разных IDE кнопки называются чуть по-разному, но базовая идея одна: есть команды управления темпом выполнения.

Нам сегодня достаточно понятия одного шага:

• выполнить следующую «видимую» операцию;
• остановиться снова;
• позволить вам посмотреть значения.

Табличка-ориентир (без привязки к конкретной IDE):

Почему одна строка не всегда один шаг

Очень хочется верить, что дебаггер будет ходить строго построчно, как учитель по журналу. Но реальность чуть хитрее: компилятор может переставлять и оптимизировать мелочи, а одна строка может содержать несколько действий.

Поэтому хорошая привычка (она окупается на 100%) — писать код так, чтобы в одной строке было одно понятное действие, особенно если вы подозреваете, что это место будете отлаживать.

Например, вот так «тяжеловато»:

int z = (x + y) * (a - b);

А вот так — дружелюбнее к дебаггеру и к будущему вам:

int sum = x + y;
int diff = a - b;
int z = sum * diff;

Да, строк стало больше. Зато вы можете пошагово проверить каждую идею: «sum действительно такой? diff не отрицательный?».

Как думать во время пошаговой отладки

Пошаговая отладка может превратиться в бессмысленное «тык-тык-тык по кнопке Step», если вы не задаёте себе правильный вопрос. Поэтому держим в голове очень практичную тройку.

Сначала вы формулируете вопрос: «Почему cnt не растёт?» или «Почему я не попал в ветку if?». Затем делаете шаг до места, где значение должно измениться. После шага фиксируете наблюдение: «cnt стал 1 и больше не меняется» или «условие оказалось false, потому что done равно false».

Это почти как детектив, только преступник — одна строчка кода, а алиби у неё железное: компилятор-то её пропустил.

5. Отладочные символы и странное поведение дебаггера

Иногда дебаггер ведёт себя как кот: делает вид, что вас не знает. Переменные «оптимизированы», шаги перескакивают, строки не совпадают. Обычно это не мистика, а одна из причин ниже.

Во-первых, вы можете запускать не ту сборку. Например, вы поправили код, но отлаживаете старый бинарник. Это случается чаще, чем хотелось бы: IDE могла не пересобрать проект, вы могли запустить «старый» target, или переключиться на другую конфигурацию.

Во-вторых, в Release (или просто при сильных оптимизациях) компилятор имеет право:

• убрать переменную, если она не нужна как «сущность» (она превратилась в вычисление в регистре);
• переставить вычисления;
• «схлопнуть» несколько строк в одну.

И дебаггер честно покажет: «я не могу вам гарантировать красивую построчность».

Поэтому правило дня простое: учиться дебажить лучше в Debug-сборке, где отладочные символы включены, а оптимизации либо выключены, либо минимальны.

6. Мини‑примеры для тренировки

Сейчас мы сделаем то, что лучше любого текста: дадим мозгу «ощутить», зачем нужен останов и step. Примеры короткие: их цель — не написать мегапроект, а научиться видеть движение программы.

Пример 1: «где я сейчас?» — базовые переменные

В этом примере вы можете запустить программу под дебаггером и пошагово пройти присваивания. На каждом шаге смотрите, как меняются x, y, z.

#include <iostream>

int main() {
    int x = 10;
    int y = 20;
    int z = x + y;
    std::cout << z << '\n'; // 30
}

Если вы делаете шаги, вы должны увидеть простую картину: сначала появляется x, потом y, потом вычисляется z. Это скучно, но это «азбука» дебага: вы учитесь видеть, что выполнение — это не магия, а последовательность действий.

Пример 2: «программа зависла» и ждёт ввод

Это тот случай, который регулярно отнимает у новичков часы жизни. Дебаггер спасает тем, что показывает: программа стоит на строке ввода и ждёт данные.

#include <iostream>

int main() {
    std::cout << "Enter n: ";
    int n = 0;
    std::cin >> n;                 // здесь программа может "висеть"
    std::cout << "n=" << n << '\n'; // например: n=5
}

Если вы запустили под дебаггером и дошли до строки std::cin >> n;, то «следующий шаг» не произойдёт, пока вы не введёте число. Это не баг. Это буквально контракт ввода: «дай мне данные».

7. Практический пример: TodoCLI и ошибка в логике

Теперь давайте привяжем дебаг к чему-то более «живому», похожему на реальный учебный проект. Представим, что у нас есть маленькое консольное приложение TodoCLI: хранит задачи в std::vector, и у задачи есть флаг done.

Мы не будем сегодня проектировать архитектуру и интерфейсы. Возьмём только один фрагмент: подсчёт выполненных задач. И специально допустим ошибку, которая не ломает компиляцию, но ломает результат — идеальный кандидат для дебаггера.

Версия без ошибки: «как должно быть»

Сначала — правильный вариант, чтобы было с чем сравнить. Обратите внимание: код короткий и предсказуемый, а значит — удобный для пошагового выполнения.

#include <cstddef>
#include <string>
#include <vector>

struct Task {
    std::string title;
    bool done;
};

int count_done(const std::vector<Task>& tasks) {
    int cnt = 0;
    for (std::size_t i = 0; i < tasks.size(); ++i) {
        if (tasks[i].done) cnt += 1;
    }
    return cnt;
}

Если вы когда-нибудь будете отлаживать эту функцию, вы ожидаете простую динамику: i растёт, cnt увеличивается только когда done == true.

Версия с ошибкой: «почему результат всегда странный»

А теперь маленькая ошибка, которая выглядит почти одинаково, компилируется, но меняет смысл. Та самая ситуация, где дебаггер — лучший друг.

#include <cstddef>
#include <string>
#include <vector>

struct Task {
    std::string title;
    bool done;
};

int count_done(const std::vector<Task>& tasks) {
    int cnt = 0;
    for (std::size_t i = 0; i < tasks.size(); ++i) {
        if (tasks[i].done) cnt =+ 1; // ОШИБКА: должно быть cnt += 1;
    }
    return cnt;
}

Что делает cnt =+ 1;? Это не «прибавить». Это «присвоить значение +1». То есть каждый раз при выполненной задаче вы делаете cnt = 1;.

Как дебаггер помогает это увидеть пошагово (чистая механика): вы запускаете отладку, доходите до цикла и делаете шаги, наблюдая два значения: i и cnt. Вы увидите, что cnt становится 1 на первой выполненной задаче… и остаётся 1 на всех следующих, хотя логически «должен расти». И в этот момент мозг говорит: «А, значит проблема в строке изменения cnt».

Мини-main, чтобы было что отлаживать

Чтобы этот кусочек был «живым», вот маленький main(), который создаёт задачи и печатает результат. Он специально короткий, потому что мы тренируем дебаг, а не пишем полноценное меню.

#include <iostream>
#include <vector>

int count_done(const std::vector<struct Task>& tasks); // допустим, объявление выше

int main() {
    std::vector<Task> tasks{
        {"Read docs", true},
        {"Fix bug", true},
        {"Go outside", false}
    };

    std::cout << count_done(tasks) << '\n'; // ожидаем 2
}

Если в вашей версии count_done с ошибкой =+, то вывод будет 1, и это отличный повод открыть дебаггер и посмотреть, где именно логика перестала соответствовать ожиданиям.

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

Ошибка №1: отлаживать программу, которая не пересобрана (или пересобрана не в той конфигурации).
Очень неприятный сценарий: вы исправили строку, уверены, что баг ушёл, запускаете дебаг — а там всё то же самое. Часто причина банальна: отлаживается старый бинарник. Приучите себя перед дебагом убедиться, что вы реально запускаете Debug-сборку и проект пересобран.

Ошибка №2: считать, что «если дебаггер остановился — значит программа сломалась».
Останов — это рабочий режим. Дебаггер может остановиться по вашей команде, на начале main(), или потому что программа дошла до контрольной точки. Сначала смотрим: где остановились и почему, и только потом делаем вывод «это баг».

Ошибка №3: перепутать «программа зависла» с «программа ждёт ввод».
Когда выполнение стоит на std::cin >> ... или std::getline(...), программа не «висит», она честно ждёт данных. Дебаггер как раз и нужен, чтобы увидеть: текущая строка — это ввод. Если вы ничего не вводите, следующий шаг не произойдёт.

Ошибка №4: шагать по коду без цели и утонуть в деталях.
Если вы просто нажимаете Step 200 раз, вы устаете и начинаете ненавидеть дебаггер (а он вообще-то хороший). Сначала формулируйте, какое значение «подозрительно», где оно должно измениться, и идите туда. Даже на уровне новичка это экономит кучу времени.

Ошибка №5: ожидать идеальной построчности в оптимизированной сборке.
В Release компилятор может «склеить» переменные и переставить вычисления. В итоге вы видите прыжки по строкам и «пропавшие» локальные переменные. Для обучения и большинства расследований используйте Debug: так дебаггеру проще связать выполнение с исходником и показать значения.