Краткий ответ

Это модули C++20: интерфейс библиотеки описывается в модульной единице трансляции, а клиентские единицы подключают его через import, а не текстово вставляют через препроцессор. Интерфейс компилируется в машинно-обрабатываемое представление, поэтому его объявления не разбираются заново в каждой единице трансляции.

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

Исторический контекст

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

Include guards и #pragma once предотвращают повторное включение одного заголовка в рамках одной единицы трансляции, но не устраняют повторную обработку между разными единицами трансляции. Модули, стандартизированные в C++20, вводят семантическую модель импорта интерфейса вместо текстового включения.

Постановка проблемы

Большой проект может тратить значительное время на обработку одних и тех же заголовков. Дополнительные риски создают конфликты макросов, случайная зависимость от порядка #include и необходимость скрывать внутренние объявления соглашениями вроде отдельных заголовков.

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

Подробное решение

Модульный интерфейс экспортирует только явно отмеченные объявления. Клиент импортирует модуль и получает доступ к экспортируемому API без текстовой вставки исходного файла:

// math.cppm
export module math;

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

// main.cpp
import math;

int main() {
    return add(2, 3) == 5 ? 0 : 1;
}

При обработке math.cppm компилятор строит интерфейс модуля и обычно сохраняет промежуточное представление, часто называемое BMI или compiled module interface. При обработке main.cpp компилятор использует это представление, а не повторно препроцессирует и разбирает весь текст math.cppm.

Ключевое отличие от заголовка состоит в границе видимости. Объявление без export остаётся внутренним для модуля; оно не становится доступным импортирующим единицам. Это уменьшает публичную поверхность и снижает вероятность случайной зависимости от реализации.

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

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

Ситуация из практики

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

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

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

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

Что кандидаты часто упускают

Вопрос: Гарантирует ли импорт модуля, что реализация модуля не будет включена в итоговый исполняемый файл?

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

Вопрос: Делает ли модуль все находящиеся в нём объявления публичными?

Ответ: Нет. Публичными для импортирующих единиц становятся только сущности, доступные через экспортируемый интерфейс. Объявления без export могут использоваться внутри самого модуля, но импортирующий код их не видит. Это позволяет физически хранить реализацию рядом с интерфейсом, не превращая её в часть API.

Вопрос: Всегда ли модульная сборка быстрее сборки с заголовками?

Ответ: Нет. Модули устраняют значительную часть повторного текстового разбора, но требуют отдельной обработки модульных интерфейсов и построения зависимостей. Если система сборки плохо кэширует BMI, часто пересобирает модули или проект содержит много мелких модулей, выигрыш может уменьшиться. Поэтому оценивают не только синтаксис import, но и граф зависимостей, стабильность интерфейсов и работу конкретного toolchain.