Этапы сборки: preprocessing → compile → link

1. Важно понимать сборку в IDE

На этом этапе курса вы уже пишете программы, которые могут состоять из нескольких файлов, и это тот момент, когда магия кнопки “Run” начинает иногда… немного подмигивать красным. Важно понять простую вещь: кнопка запуска в IDE — это не одна операция, а целая цепочка шагов. И когда что-то ломается, полезно уметь сказать: «Окей, это сломалось на шаге, где склеивают файлы», или «Это ещё раньше: файл даже не смог нормально прочитаться через #include».

В C++ сборка почти всегда разбивается на три крупные стадии:

• preprocessing (препроцессирование),
• compile (компиляция),
• link (линковка).

Мы будем говорить про них без командной строки (никаких страшных g++ -std=c++23 ...), только как про внутренний конвейер, который IDE делает за вас.

Большая карта: от .cpp до запуска программы

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

В виде схемы это выглядит так:

flowchart LR
    A[".cpp + #include .hpp"] -->|preprocessing| B["translation unit (текст после #include/#define)"]
    B -->|compile| C["object file (.o/.obj)"]
    C -->|link| D["executable (программа)"]

Ниже — табличка «вход → выход», чтобы было за что зацепиться глазами:

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

2. Preprocessing: когда #include — это «копипаст, но официальный»

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

Что делает #include на самом деле

#include "file.hpp" означает: «возьми содержимое file.hpp и вставь сюда». Прямо как Ctrl+C/Ctrl+V, только без чувства стыда и с поддержкой промышленной разработки.

Представим, что мы продолжаем наше учебное консольное приложение TaskBook (простейший список задач). Мы держим интерфейс (объявления) в .hpp, а реализацию — в .cpp.

task.hpp (заголовок, объявления):

#pragma once
#include <string>

void addTask(std::string title);

main.cpp:

#include <iostream>
#include "task.hpp"

int main() {
    addTask("Read about linker");
    std::cout << "OK\n"; // OK
}

Когда препроцессор обработает main.cpp, он как будто получит «единый текст», где на месте #include "task.hpp" окажется содержимое заголовка (плюс содержимое тех заголовков, которые подключил он, например <string>). Компилятор потом анализирует уже это.

И здесь важно: препроцессор не понимает C++ как язык. Он не знает, что такое «функция», «тип», «шаблон». Он работает с текстом и директивами #....

Макросы: подстановка текста, а не «маленькие функции»

Макрос — это тоже чисто текстовая штука. Это значит, что он не соблюдает правила типов, областей видимости и вообще ведёт себя так, как будто вы вручную заменили кусок текста.

Пример:

#include <iostream>

#define SQUARE(x) ((x) * (x))

int main() {
    std::cout << SQUARE(1 + 2) << '\n'; // 9
}

Тут скобки спасают нас от классической ловушки приоритетов. Если бы мы написали #define SQUARE(x) x * x, то SQUARE(1 + 2) превратилось бы в 1 + 2 * 1 + 2, и результат был бы… сюрпризом. Такой сюрприз особенно обиден, потому что компилятор формально не обязан понимать, что вы хотели «квадрат числа», он видит корректное выражение.

Условная компиляция: код, который «существует» не всегда

Ещё один важный инструмент препроцессора — условная компиляция. Это когда часть кода включается или исключается до компиляции.

Например, заведём простую настройку для диагностики:

config.hpp:

#pragma once
#define ENABLE_DIAGNOSTICS 1

main.cpp:

#include <iostream>
#include "config.hpp"

int main() {
#if ENABLE_DIAGNOSTICS
    std::cout << "Diagnostics ON\n"; // Diagnostics ON
#endif
    std::cout << "Run\n";            // Run
}

Здесь компилятор увидит либо оба std::cout, либо только "Run", в зависимости от значения макроса. То есть для компилятора «вырезанного» кода как будто вообще не существует.

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

4. Единица трансляции: что это и почему важно

Слово «единица трансляции» звучит так, будто мы сейчас начнём переводить Шекспира. На деле это очень практичное понятие: единица трансляции — это то, что получается из одного .cpp после препроцессора. То есть .cpp плюс всё, что в него включилось через #include (прямо и косвенно), плюс развёрнутые макросы, плюс вырезанные #if.

Почему это важно? Потому что компиляция происходит по единицам трансляции. То есть если у вас есть main.cpp, task.cpp, storage.cpp, то у вас будет три отдельные единицы трансляции, и компилятор обработает их по отдельности.

Это объясняет сразу две «странности», которые вы наверняка уже видели.

• Первая странность: «Почему я написал функцию в task.cpp, но в main.cpp компилятор говорит, что такой функции нет?» Потому что компилятор компилирует main.cpp отдельно и должен увидеть объявление (обычно через .hpp) прямо в main.cpp после #include.
• Вторая странность: «Почему если я определю переменную в заголовке, оно внезапно ломается во многих файлах?» Потому что заголовок включится в несколько единиц трансляции, и одно и то же определение размножится. Это как раз то место, где в прошлых лекциях всплывала тема ODR: один проект, одно определение сущности (в нужном смысле).

5. Compile: компиляция как «сборка деталей по отдельности»

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

Что такое объектный файл и почему вы его редко видите

Объектный файл (.o или .obj) — это результат компиляции одного .cpp. IDE обычно прячет эти файлы в служебных папках, чтобы не мозолили глаза, но логически можно думать так:

• там уже есть машинный код для функций из этого .cpp,
• там есть информация о том, какие символы (функции/глобальные переменные) этот файл предоставляет,
• и какие символы он использует, но не определяет (например, вызывает функции из других .cpp).

Если вернуться к нашему TaskBook, то task.cpp после компиляции станет «коробкой с деталями»: внутри реализация addTask, но коробка ещё не является готовой программой.

Почему компиляция может пройти, даже если программу ещё не собрать

Вот частая ситуация, которая кажется парадоксом, но на самом деле полностью логична.

task.hpp:

#pragma once
#include <string>

void addTask(std::string title);

main.cpp:

#include <iostream>
#include "task.hpp"

int main() {
    addTask("Buy milk");
    std::cout << "done\n"; // done
}

Этот main.cpp вполне компилируется, потому что компилятору достаточно знать объявление addTask. Он видит: «ок, есть функция, она принимает std::string, возвращает void». Компилятор может сгенерировать код вызова.

Но где лежит тело addTask? Это уже не проблема компиляции main.cpp. Это станет проблемой позже, на линковке, если реализации нет или она не участвует в сборке.

Почему изменение .hpp часто «перекомпилирует полпроекта»

Если вы меняете .cpp, IDE обычно перекомпилирует только этот .cpp. Но если вы меняете заголовок .hpp, который включают многие .cpp, то IDE вынуждена перекомпилировать все затронутые единицы трансляции, ведь после препроцессора у них поменялся итоговый текст.

Это одна из причин, почему мы в прошлых днях говорили «include what you use» и «не тащите в .hpp лишнее»: заголовки сильно влияют на время сборки.

6. Link: склейка объектных файлов в одну программу

Линковка — это финальная стадия: мы берём несколько объектных файлов и получаем один исполняемый файл (программу), которую уже можно запускать. Если компиляцию можно сравнить с изготовлением деталей конструктора, то линковка — это инструкция «как соединить всё в одну модель, чтобы она не развалилась при первом “Run”».

Что значит «связать символы»

Когда main.cpp вызывает addTask(...), в объектном файле main.o будет запись примерно такого смысла: «мне нужна функция addTask(std::string)». А в объектном файле task.o будет запись: «а вот она, функция addTask(std::string), берите».

Линковщик делает «свадебного ведущего» для этих двух: находит, где определён нужный символ, и связывает вызов с реализацией.

• Если реализация не найдена — линковщик не может собрать программу.
• Если реализация найдена в двух разных объектных файлах (то есть вы определили одно и то же два раза) — линковщик тоже будет недоволен, потому что непонятно, какую из двух реализаций считать настоящей.

Мини-пример «объявили, но не определили»

Сделаем маленький пример в стиле «как это выглядит в проекте».

math.hpp:

#pragma once
int add(int a, int b);

main.cpp:

#include <iostream>
#include "math.hpp"

int main() {
    std::cout << add(2, 3) << '\n'; // хотим 5
}

Если в проекте нет math.cpp с реализацией add, то main.cpp может скомпилироваться, но программа не соберётся целиком. Именно потому, что «позвать функцию можно, зная объявление», а «реально выполнить вызов можно, только если где-то есть тело».

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

7. Как мыслить о стадиях сборки

Как определить стадию по симптомам

После сегодняшней лекции у вас должна появиться привычка: когда что-то пошло не так, вы мысленно спрашиваете: «На какой стадии это произошло?». Это сильно помогает не метаться по коду хаотично.

• Если проблема связана с #include (файл не подключился, макрос странно подставился, кусок кода «исчез»), то это почти всегда зона препроцессора.
• Если проблема связана с тем, что «код не понимается как C++» (синтаксис, типы, «не могу преобразовать», «нет такого метода»), то это зона компиляции.
• Если проблема связана с тем, что «всё было нормально, но в конце что-то не сошлось» (не нашлась реализация, нашлось две реализации), то это зона линковки.

И да: вы не обязаны помнить все эти слова. Главное — держать в голове, что кнопка “Run” в IDE делает не одну магию, а три. (Если бы это была одна магия, C++ был бы слишком добрым языком, а это подозрительно.)

Практический пример: TaskBook проходит весь конвейер

Сейчас аккуратно соберём мини-версию TaskBook из трёх файлов, чтобы увидеть полный путь без лишней сложности. Заметьте: примеры маленькие, но структура уже «взрослая»: интерфейс в .hpp, реализация в .cpp, использование в main.cpp.

task.hpp:

#pragma once
#include <string>

void addTask(const std::string& title);

task.cpp:

#include "task.hpp"
#include <iostream>

void addTask(const std::string& title) {
    std::cout << "Added: " << title << '\n'; // Added: ...
}

main.cpp:

#include "task.hpp"

int main() {
    addTask("Learn preprocessing");
    addTask("Learn compilation");
}

Теперь мысленно прогоняем сборку.

• Сначала preprocessing для main.cpp: он вставит содержимое task.hpp (и там, в свою очередь, вставится <string>). После этого компилятор увидит объявление addTask.
• Потом compile: main.cpp превращается в объектный файл, где есть main() и есть «вызовы addTask, реализация где-то будет». Отдельно компилируется task.cpp: там появляется реальная функция addTask.
• Потом link: линковщик соединяет main() и addTask в одну программу. И только после этого её можно запускать.

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

Ошибка №1: думать, что компилятор “видит весь проект сразу”.
Это одна из самых частых ментальных ловушек. Кажется логичным: «ну у меня же проект, там все файлы рядом». Но по факту компиляция идёт по одному .cpp. Поэтому, если вы не подключили нужный .hpp, то «рядом лежащий task.cpp» не спасёт: компилятор в момент компиляции main.cpp про него ничего не обязан знать.

Ошибка №2: ожидать от препроцессора понимания типов и областей видимости.
Препроцессор работает с текстом. Он не знает, что такое std::string, не знает, что такое «переменная», и не умеет «аккуратно подставить макрос». Он просто заменит кусок текста. Поэтому макросы без скобок, хитрые #define, странные #if часто дают эффекты, которые выглядят как баги компилятора, хотя на деле это текстовая подстановка.

Ошибка №3: держать определения в заголовках “потому что так проще”.
Новичкам очень хочется всё писать в .hpp, чтобы «точно было видно». Но заголовок подключается во многие .cpp, и определения (особенно глобальных переменных и не-inline функций) начинают размножаться. Это может привести к тому, что финальная сборка не получится: линковщик увидит несколько одинаковых определений и откажется собирать программу.

Ошибка №4: путать “файл существует” и “файл участвует в сборке”.
Даже если task.cpp лежит в папке проекта, это ещё не гарантирует, что IDE добавила его в сборку. В некоторых средах файл нужно явно включить в target/проект. Тогда компиляция отдельных файлов может проходить, но на финальном шаге «склейки» окажется, что нужной реализации как будто нет.

Ошибка №5: лечить проблемы стадии link правками в коде, который компилируется.
Когда программа «не собирается целиком», рука тянется переписывать main.cpp, добавлять #include, менять сигнатуры наугад. Часто это превращается в хаос. Гораздо спокойнее сначала спросить себя: «моя проблема точно на линковке? тогда я ищу несоответствие объявлений/определений или отсутствие нужного .cpp в сборке». Такой подход экономит часы и снижает уровень желания «уйти в Python» (хотя Python не виноват).