Препроцессор

Что такое препроцессор и зачем он нужен

Когда вы нажимаете "скомпилировать", ваш .cpp-файл не попадает напрямую в компилятор C++. Сначала над ним работает отдельная программа — препроцессор. Её задача проста и конкретна: текстовая обработка исходника по набору директив, начинающихся с #.

Препроцессор ничего не знает о C++ как языке — ни об областях видимости, ни о типах, ни о перегрузке функций. Он работает с токенами: находит директивы, вставляет файлы, разворачивает макросы, вырезает неактивные условные ветки. Результат этой работы — единица трансляции (translation unit) — это то, что компилятор видит в действительности.

Место препроцессора в сборке C++↗

Это важно понимать, потому что ошибки препроцессора (неправильный include, сломанный макрос, незакрытый #if) часто превращаются в непонятные ошибки компилятора — в месте, далёком от настоящей причины.

Подробнее о месте препроцессинга в сборке программы.

Терминология

• Директива — строка, начинающаяся с #: #include, #define, #if, #pragma.
• Макрос — имя, которое препроцессор заменяет на другой набор токенов.
• Object-like macro — макрос без параметров: #define BUFFER_SIZE 4096.
• Function-like macro — макрос с параметрами: #define MAX(a, b) ....
• Translation unit — то, что получается после препроцессинга: именно его компилятор и компилирует.
• Include guard — конструкция, защищающая заголовок от повторного включения.
• Условная компиляция — выбор кода через #if, #ifdef, #ifndef, #elif, #else, #endif.

#include: физическая вставка текста

#include буквально вставляет содержимое другого файла в текущую единицу трансляции:

#include <vector>       // стандартный или системный заголовок
#include "player.hpp"   // заголовок проекта

Разница между угловыми и двойными кавычками — в порядке поиска файла:

• #include "file.hpp" обычно сначала ищет рядом с текущим файлом, затем в include paths;
• #include <file.hpp> ищет в системных и настроенных include paths.

Точный порядок зависит от компилятора и параметров сборки. Суть в том, что каждый #include увеличивает объём текста, который компилятор обрабатывает. Тяжёлые заголовки, лишние include и циклические зависимости напрямую замедляют сборку.

Include guards и #pragma once

Если заголовок включить несколько раз через цепочку include, определения классов и функций продублируются, и компилятор выдаст ошибку.

Классический include guard:

#ifndef PROJECT_ENGINE_PLAYER_HPP
#define PROJECT_ENGINE_PLAYER_HPP

struct Player {
    int health = 100;
};

#endif

При первом включении PROJECT_ENGINE_PLAYER_HPP не определён — содержимое проходит. При повторном включении макрос уже определён — весь блок до #endif вырезается.

Имя guard должно быть уникальным для каждого файла. Два разных заголовка с одинаковым именем guard могут молча "заглушить" один из файлов — ошибки компилятора при этом могут выглядеть совершенно иначе.

#pragma once:

#pragma once

struct Player {
    int health = 100;
};

Короче и удобнее, но формально не входит в стандарт C++. На практике поддерживается GCC, Clang и MSVC. Редкие проблемы возможны с нестандартными файловыми системами, symlinks и generated headers, где один и тот же физический файл виден под разными путями.

В большинстве проектов сегодня используют #pragma once. Для максимальной переносимости на экзотические toolchains лучше include guard.

#define: объект-макросы и function-like макросы

#define создаёт имя, которое препроцессор заменяет на заданный текст при каждом встречном вхождении.

Object-like макрос — замена простого имени:

#define BUFFER_SIZE 4096

char buffer[BUFFER_SIZE];  // препроцессор заменит на: char buffer[4096];

Function-like макрос — с параметрами:

#define SQUARE(x) x * x

int value = SQUARE(2 + 3);
// После подстановки: int value = 2 + 3 * 2 + 3; — это 11, а не 25

Классическая ловушка: макрос не вычисляет, он подставляет токены. Из-за этого приоритет операторов может сломать результат. Решение — скобки вокруг каждого аргумента и вокруг всего выражения:

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

int value = SQUARE(2 + 3);  // ((2 + 3) * (2 + 3)) = 25

Но скобки не решают всех проблем. Смотрите раздел о повторном вычислении ниже.

#undef удаляет ранее определённый макрос:

#undef BUFFER_SIZE

Почему #define — плохой заменитель констант и функций

В старом C-коде #define использовался для констант и функций. В C++ это устарело, потому что у макросов нет типов, нет области видимости, нет проверок компилятора.

#define vs constexpr: ключевые отличия↗

Современные замены:

// Вместо #define BUFFER_SIZE 4096
inline constexpr std::size_t buffer_size = 4096;

// Вместо #define SQUARE(x) ((x) * (x))
template <typename T>
constexpr T square(T x) {
    return x * x;
}

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

Ловушки макросов: подробный разбор

Повторное вычисление аргументов

Даже правильно расставленные скобки не спасают, если аргумент имеет побочный эффект:

#define MAX(a, b) ((a) > (b) ? (a) : (b))

int i = 0;
int x = MAX(++i, 10);
// Раскрывается в: ((++i) > (10) ? (++i) : (10))
// ++i может быть вычислен дважды — поведение непредсказуемо

Правильное решение — шаблонная функция:

template <typename T>
constexpr const T& max_value(const T& a, const T& b) {
    return a < b ? b : a;
}

Коллизии имён со стандартной библиотекой

Широко известная проблема: заголовки Windows (<windows.h>) определяют MAX и MIN как макросы. Это ломает std::max и std::min:

#include <windows.h>
#include <algorithm>

// ОПАСНО: MAX из windows.h подменяет std::max
int x = std::max(1, 2);  // может не скомпилироваться или дать неверный результат

// Защита: отключить макросы через NOMINMAX перед включением windows.h
#define NOMINMAX
#include <windows.h>

Это один из самых распространённых источников неочевидных ошибок при портировании кода под Windows.

Макрос без скобок

// ОПАСНО: приоритет операторов сломает результат
#define ADD(a, b) a + b

int x = ADD(2, 3) * 4;
// Раскрывается в: 2 + 3 * 4 = 14, а не 20

// Правильно:
#define ADD(a, b) ((a) + (b))

Макрос не уважает namespace и область видимости

Имя макроса не принадлежит никакому namespace. Если вы написали #define SIZE 100 в одном заголовке, это имя глобально "заражает" все файлы, которые включат этот заголовок. Отменить его можно только через #undef.

Многострочные макросы и do { } while (0)

Если макрос раскрывается в несколько statements, его оборачивают в do { ... } while (0), чтобы он вёл себя как один statement в if/else:

#define LOG_AND_RETURN(msg) \
    do {                    \
        log(msg);           \
        return;             \
    } while (0)

if (failed)
    LOG_AND_RETURN("failed");  // работает корректно даже без фигурных скобок
else
    continue_work();

Без обёртки if (failed) log(msg); return; — return выполнился бы всегда.

Продвинутые возможности: # и ##, variadic macros

Stringification (#)

# превращает аргумент макроса в строковой литерал:

#define TRACE_EXPR(expr) log(#expr, (expr))

int x = 5, y = 3;
TRACE_EXPR(x + y);
// Раскрывается в: log("x + y", (x + y))
// Выведет: x + y = 8

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

Token pasting (##)

## склеивает два токена в один:

#define MAKE_ID(prefix, num) prefix##num

int MAKE_ID(user_, 42) = 100;  // int user_42 = 100;

Используется для генерации уникальных имён в системах X-macro и генерации кода.

Variadic macros (__VA_ARGS__)

#define LOG(fmt, ...) log_impl(__FILE__, __LINE__, fmt, __VA_ARGS__)

LOG("user %d connected", user_id);
// Раскрывается в: log_impl("main.cpp", 42, "user %d connected", user_id)

Полезны для logging-обёрток, assert-макросов и API, где нужно автоматически захватить __FILE__/__LINE__. Но если макрос начинает расти в мини-язык — это сигнал пересмотреть архитектуру.

X-macro: генерация кода без дублирования

X-macro — паттерн, при котором одна "таблица" данных используется для генерации нескольких конструкций: enum, массивов строк, switch-кейсов и т.д.

// Определяем таблицу один раз
#define ERROR_CODES \
    X(OK,          "Success")         \
    X(NOT_FOUND,   "Not found")       \
    X(TIMEOUT,     "Timeout")

// Генерируем enum
enum ErrorCode {
#define X(code, msg) code,
    ERROR_CODES
#undef X
};

// Генерируем массив строк
const char* error_messages[] = {
#define X(code, msg) msg,
    ERROR_CODES
#undef X
};

X-macro устраняет дублирование, когда список элементов должен синхронно отражаться в нескольких местах кода. В современном C++ похожего эффекта можно достичь через constexpr массивы и шаблоны, но X-macro всё ещё встречается в low-level и embedded коде.

Условная компиляция

#if, #ifdef, #ifndef, #elif, #else, #endif выбирают, какой код попадёт в translation unit:

#if defined(_WIN32)
    // Windows-specific код
#elif defined(__linux__)
    // Linux-specific код
#else
    #error Неподдерживаемая платформа
#endif

#ifdef DEBUG
    std::cerr << "debug mode\n";
#endif

Практический совет: держите условную компиляцию локализованной. Если #ifdef разбросаны по бизнес-логике, код быстро становится трудно читать, тестировать и поддерживать. Лучше изолировать платформенный код за обычным C++-интерфейсом:

// Плохо: #ifdef по всему коду
void open_file(const char* path) {
#if defined(_WIN32)
    // Windows API
#else
    // POSIX API
#endif
}

// Лучше: один платформенный слой, остальной код чистый
FileHandle open_native_file(std::string_view path);  // реализация в platform.win.cpp / platform.posix.cpp

Predefined macros и feature detection

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

__FILE__      // путь к текущему файлу (строковой литерал)
__LINE__      // текущая строка (целое число)
__func__      // имя текущей функции (строковой литерал, C99/C++11)
__cplusplus   // версия стандарта: 201703L (C++17), 202002L (C++20), 202302L (C++23)

Для feature detection предпочтительны стандартные feature-test macros:

#ifdef __cpp_consteval
    // consteval поддерживается
#endif

#ifdef __cpp_modules
    // модули C++20 доступны
#endif

#error останавливает сборку с понятным сообщением — удобно для проверки конфигурации:

#ifndef PROJECT_CONFIGURED
#error "PROJECT_CONFIGURED must be defined by the build system"
#endif

#line меняет информацию о строке и файле в диагностике. Встречается в сгенерированном коде (например, yacc/bison генерирует #line директивы, чтобы сообщения об ошибках указывали на исходную грамматику, а не на сгенерированный C++-файл).

Как посмотреть результат препроцессинга

Компилятор можно остановить после препроцессинга и посмотреть, что реально попадёт в компилятор:

g++ -E main.cpp -o main.i
clang++ -E main.cpp -o main.i
cl /P main.cpp           # MSVC: создаёт main.i

Это неоценимо при отладке сложных макросов и неочевидных ошибок include. Вы видите точный текст, с которым будет работать компилятор.

Посмотреть все предопределённые макросы в GCC/Clang:

g++ -dM -E -x c++ /dev/null

Сгенерировать файлы зависимостей для build system (Makefile, Ninja):

g++ -MMD -MP -c main.cpp

Когда макрос всё ещё оправдан

Препроцессор не устарел — он просто занял свою нишу. В реальных проектах он нужен для:

• Include guards — пока не везде используются модули C++20.
• Платформенные ветки — когда код буквально не должен компилироваться на другой платформе.
• Feature flags и compile-time конфигурация — build-система определяет -DENABLE_LOGGING, код реагирует через #ifdef.
• Экспорт символов библиотек — MY_LIB_API разворачивается в __declspec(dllexport) или __attribute__((visibility("default"))) в зависимости от платформы.
• Logging/assert с __FILE__, __LINE__ — обычная функция не знает место вызова (в C++20 частично решает std::source_location, но макрос проще).
• X-macro паттерны в низкоуровневом коде.
• Сгенерированный код — yacc, protobuf и другие генераторы используют директивы.

Хороший C++-код держит препроцессор на границах системы. Внутри бизнес-логики лучше использовать язык: типы, функции, шаблоны, constexpr, enum class, namespaces и модули.

Частые ошибки

• Макрос без скобок вокруг аргументов: #define ADD(a, b) a + b.
• Передача выражения с побочными эффектами в function-like макрос: MAX(++i, j).
• Использование #define для константы вместо constexpr, для функции вместо inline/шаблона.
• Неуникальный include guard: два разных файла с одинаковым именем guard молча глушат один из них.
• Широкие #ifdef по всему бизнес-коду — замените платформенным слоем абстракции.
• Ожидание, что макрос уважает namespace, overload resolution или access modifiers.
• MAX/MIN из <windows.h> ломают std::max/std::min — решение: #define NOMINMAX перед включением.
• Определение функций или переменных в заголовке без inline — при включении в несколько единиц трансляции это даёт linker error "multiple definitions".
• Зависимость от нестандартного #pragma без проверки компилятора.

Значение для собеседований

Тема препроцессора — постоянная часть технических собеседований по C++, особенно в контексте сборки и понимания языка на уровне ниже стандартной семантики.

Что проверяет интервьюер: не знание синтаксиса #define, а понимание, почему макросы опасны, что происходит до компиляции, и какие языковые средства их заменяют.

Три главных направления вопросов:

1. #define против const/constexpr/inline — почему макрос не эквивалентен константе; отсутствие типа, scope, проверок компилятора; повторное вычисление аргументов.

1. Include guards против #pragma once — что такое ODR (One Definition Rule), как guard предотвращает дублирование, почему #pragma once не стандарт и когда это важно.

1. Ловушки макросов — приоритет операторов без скобок, multiple evaluation, коллизии имён (MIN/MAX из Windows.h), отсутствие типобезопасности.

Дополнительные направления: условная компиляция (зачем и как изолировать), __FILE__/__LINE__ и когда макрос незаменим, X-macro паттерн, g++ -E для диагностики.

Типичная ошибка кандидата: "макрос и const — это одно и то же, просто разный синтаксис". Сильный ответ объясняет, что const — это C++-объект с типом, областью видимости и видимостью в отладчике, а макрос исчезает до компиляции и не подчиняется никаким правилам языка.

Частые вопросы-ловушки:

• "Почему SQUARE(1 + 2) без скобок даёт не 9?"
• "Что произойдёт, если два заголовка используют одинаковый include guard?"
• "Почему MAX(++i, j) опасен?"
• "Чем #include <...> отличается от #include "..."?"
• "Когда макрос всё ещё оправдан в современном C++?"
• "Как посмотреть, что видит компилятор после препроцессинга?"

Кратко

Препроцессор — первый шаг сборки: он вставляет заголовки, разворачивает макросы и вырезает неактивные ветки, превращая исходный файл в единицу трансляции. Он работает с текстом, а не с C++-семантикой — именно поэтому макросы не знают ни типов, ни областей видимости, ни overload resolution. В современном C++ их заменяют constexpr, inline-функции, шаблоны и модули — везде, где это возможно. Препроцессор остаётся нужным для границ сборки, платформенной конфигурации, экспорта символов и случаев, когда нужно автоматически захватить __FILE__/__LINE__.