Каждый .cpp компилируется отдельно

1. Раздельная компиляция и единица трансляции

Когда вы учитесь, один файл — это нормально: меньше переключений, легче копировать, проще сдавать задачи. Но как только программа начинает жить дольше одного вечера, появляется типичная ситуация: main.cpp разрастается, как «папка Загрузки» у человека, который верит, что когда-нибудь всё разберёт. В одном месте у вас ввод, в другом — расчёты, рядом — печать моделей, и всё это переплетено так, что страшно лишний пробел тронуть.

Многофайловый проект позволяет разложить код по смыслу: отдельно «логика», отдельно «ввод-вывод», отдельно «модели данных». И важный момент: мы делим код не для компилятора, а для людей. Компилятор, если честно, готов проглотить и огромный файл — но вам потом в этом жить.

Начиная с сегодняшней темы, мы будем постепенно приводить наш учебный проект к более взрослому виду. Представим, что у нас есть маленькое консольное приложение «Список дел» (todo): оно хранит задачи в std::vector<std::string>, печатает список и позволяет добавлять новую задачу. Пока всё это было в одном main.cpp. Сегодня мы попробуем вынести часть функций в отдельный .cpp — и на этом как раз поймаем главную идею лекции.

Компилятор компилирует каждый .cpp отдельно

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

Почему так сделано? Потому что это удобно и быстро для больших проектов. Если вы изменили одну функцию в одном .cpp, было бы странно перекомпилировать вообще всё на свете. Отдельная компиляция позволяет пересобрать только изменившиеся части.

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

Представьте, что у вас две контрольные работы в двух аудиториях. В аудитории №1 вы написали прекрасную формулу на листочке. В аудитории №2 преподаватель проверяет другой листочек и знать не знает, что вы там написали в первой аудитории. Вот примерно так ведут себя разные .cpp: каждый живёт своей жизнью.

Что такое единица трансляции

Теперь вводим ключевой термин: единица трансляции (translation unit).

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

текущий .cpp + текст всех заголовков, которые в него включили (прямо или косвенно)

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

У стандарта C++ есть формальные стадии «перевода» исходника; среди них есть этап, на котором после работы препроцессора формируется то, что компилятор рассматривает как единицу трансляции. В рабочих материалах стандарта это привязывают к фазам трансляции и подчёркивают, что понятие translation unit связано именно с этими фазами.

Полезная мини-схема (очень упрощённая, но рабочая для головы):

flowchart TD
    A[main.cpp + #include ...] --> B[Препроцессор: вставил текст заголовков]
    B --> C[Единица трансляции]
    C --> D[Компиляция: проверка синтаксиса/типов, генерация объектного кода]
    D --> E[... потом “склеивание” всех частей в программу]

Сегодня нам важно именно место «Единица трансляции»: это граница видимости на этапе компиляции одного файла.

3. Практика: почему .cpp не «видят» друг друга

Минимальный пример: «функция есть, но компилятор её не знает»

Давайте сделаем самый минимальный пример, который демонстрирует проблему.

Вариант A: «кажется, всё должно работать»… но нет

math.cpp:

int add(int a, int b) {
    return a + b;
}

main.cpp:

#include <iostream>

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

Логика новичка понятна: «функция же есть, вот она, в соседнем файле». Но компилятор компилирует main.cpp отдельно. В единице трансляции main.cpp имени add нет. Поэтому ошибка будет примерно такая (формулировка зависит от компилятора/IDE): "error: 'add' was not declared in this scope".

То есть: «я не знаю, что такое add».

Вариант B: добавили объявление — компилятор уже доволен

Теперь добавим объявление функции в main.cpp — просто одну строку, без тела:

main.cpp:

#include <iostream>

int add(int a, int b); // объявление: “такая функция существует”

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

math.cpp остаётся тем же:

int add(int a, int b) {
    return a + b;
}

Теперь при компиляции main.cpp компилятор уже знает сигнатуру add(int, int) и может проверить корректность вызова. Тело функции ему не обязательно видеть на этом этапе — достаточно объявления.

И вот тут появляется дисциплина, которую мы будем развивать дальше: вызов в одном .cpp, реализация в другом .cpp, а объявление должно быть доступно там, где вызываем.

Вариант C: почему нельзя «просто вставить соседний .cpp через include»

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

Мини-пример: выносим печать задач в отдельный файл

Сделаем это на чём-то чуть более живом, чем add. Пусть у нас есть мини-приложение «Todo»: мы хотим печатать задачи и добавлять новые. Раньше всё было в main.cpp, но теперь попробуем вынести «печать списка» в отдельный файл todo_print.cpp.

Шаг 1: в main.cpp мы вызываем функцию печати

main.cpp:

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

void print_tasks(const std::vector<std::string>& tasks); // объявление

int main() {
    std::vector<std::string> tasks = {"Buy milk", "Learn C++"};

    print_tasks(tasks);
    std::cout << "Done!\n"; // Done!
}

Обратите внимание на стиль: сначала объявление, потом использование. Это позволяет main.cpp компилироваться независимо.

Шаг 2: реализацию кладём в todo_print.cpp

todo_print.cpp:

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

void print_tasks(const std::vector<std::string>& tasks) {
    for (std::size_t i = 0; i < tasks.size(); ++i) {
        std::cout << (i + 1) << ") " << tasks[i] << '\n';
    }
}

Этот код простой, но он уже показывает важный момент: каждый .cpp должен включать то, что ему нужно. todo_print.cpp использует std::vector, std::string, std::cout — значит, он обязан подключить <vector>, <string>, <iostream>. Нельзя надеяться, что «в main.cpp уже подключено».

Если вы забудете #include <vector>, компилятор, обрабатывая todo_print.cpp, не обязан «помнить», что где-то в проекте был <vector>. Он компилирует файл отдельно — и это снова возвращает нас к модели единиц трансляции.

Что мы получили в голове

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

Но именно сейчас важно почувствовать главную механику: main.cpp и todo_print.cpp компилируются как разные миры, и единственный способ обменяться знаниями между ними — сделать так, чтобы нужные объявления попали в оба мира.

4. Почему нельзя #include "something.cpp" и как чинить «не найдено имя»

Почему #include "something.cpp" — плохая идея

Очень часто новичок находит «быстрое решение»: если main.cpp не видит функцию из math.cpp, давайте просто вставим math.cpp внутрь main.cpp с помощью #include. Формально это может сработать: текст math.cpp окажется в единице трансляции main.cpp, компилятор увидит определение функции, и всё «вроде бы» заработает.

Проблема в том, что вы случайно превращаете проект в «один огромный файл, собранный из кусков». И это ломает сразу несколько вещей.

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

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

Как думать, когда компилятор ругается «не найдено имя»

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

Если компилятор говорит что-то вроде:

• was not declared in this scope
• use of undeclared identifier
• «не удалось найти идентификатор …»

то это почти всегда означает одну из двух ситуаций.

Первая ситуация — вы реально забыли объявить имя до использования в пределах одного файла. Это классика, вы уже с ней знакомы ещё со времён функций: написали main, вызвали foo(), а объявление foo ниже — компилятор не видит.

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

Полезная микро-таблица для самопроверки (без фанатизма, просто как ориентир):

И ещё один «профессиональный» трюк мышления: когда вы видите ошибку, всегда задавайте себе вопрос: «В каком файле компилятор сейчас находится?» Ошибка почти всегда указывает файл и строку. Это не мелочь. Это подсказка: «в этой единице трансляции нужного имени нет».

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

Ошибка №1: ожидать, что «если функция есть в проекте, её увидят везде».
Это интуиция из «одного файла»: там действительно всё видно везде, если вы правильно расположили код. В многофайловой модели это перестаёт быть правдой. Каждый .cpp компилируется отдельно, и соседний .cpp не является «продолжением» текущего. Лечится привычкой: где используешь имя — там должно быть его объявление (обычно через #include заголовка).

Ошибка №2: писать объявление функции «на глаз» в нескольких местах и случайно сделать их разными.
Новички часто копируют сигнатуру руками: в одном файле int add(int, int);, в другом вдруг стало long add(int, int); или добавился const. Компилятор может начать ругаться странно, а вы будете смотреть на код и думать «ну почти же одинаково». Правильная привычка: объявление должно быть одно (в заголовке), а остальные файлы должны его подключать. Сегодня мы это только обозначили, а в следующей лекции оформим как норму.

Ошибка №3: подключать .cpp через #include, потому что «так быстрее».
Это тот самый вредный лайфхак, который кажется рабочим, пока проект маленький. Потом он начинает жить своей жизнью: удлиняет сборку, провоцирует конфликты, делает структуру проекта нечитаемой и превращает отладку в археологию. Дисциплина простая: подключаем заголовки, .cpp компилируем отдельно.

Ошибка №4: забывать, что каждый .cpp должен иметь свои #include для используемых типов.
Часто выглядит так: вы перенесли функцию в utils.cpp, а она использует std::string, и внезапно компилятор говорит, что std::string не существует. Кажется странным: «но в main.cpp же был <string>!». А вот utils.cpp — отдельная единица трансляции. Если тип используется в этом файле, значит, нужный стандартный заголовок должен быть подключён именно в этом файле.

Ошибка №5: паниковать и «лечить» ошибки добавлением #include <bits/stdc++.h> или десятка лишних заголовков.
Иногда хочется просто «насыпать инклудов», чтобы всё заткнулось. Это работает как скотч на протекающей трубе: на минуту стало тише, но проблема не решена. Гораздо полезнее понять: какое имя не найдено, в каком .cpp оно используется, и какое объявление должно попасть в единицу трансляции. Тогда вы добавляете ровно то, что нужно — и начинаете управлять кодом, а не умолять его работать.