Модули

export помечает объявление как часть публичного API модуля, делая его видимым всем, кто пишет import. Объявления без export остаются внутренними для модуля. export также образует само объявление модуля: export module name;.

#include — это текстовая подстановка препроцессора: текст заголовка вставляется и парсится заново. import загружает уже скомпилированный Binary Module Interface, поэтому макросы не утекают, порядок импортов не важен, и видны только экспортированные имена.

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

BMI — сгенерированный компилятором бинарный файл, хранящий уже разобранное семантическое представление интерфейса модуля. Потребители читают BMI вместо .cppm. Расширения разные: .gcm (GCC), .pcm (Clang), .ifc (MSVC).

Интерфейсный юнит начинается с export module name; и объявляет публичный API модуля — именно его видит import потребителя. Юнит реализации начинается с module name; (без export) и лишь определяет тела; потребители его не видят и не компилируют напрямую.

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

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

Макросы — понятие препроцессора без области видимости, и прекращение их неконтролируемой утечки — одна из главных целей модулей. import передаёт скомпилированные семантические сущности, а не текст препроцессора, поэтому #define внутри модуля просто не доходит до потребителя.

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

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

export import X; импортирует модуль или раздел X и реэкспортирует его экспортированные имена всем, кто импортирует текущий модуль. Обычный import X; оставляет X приватным; export import строит модули-фасады и собирает разделы в первичный интерфейс.

Это область, открываемая голой строкой module; перед export module name;, где разрешены legacy-директивы #include. Подтянутые туда сущности доступны внутри модуля, но не экспортируются потребителям — это мост совместимости со старыми заголовками.

Header unit — существующий заголовок, скомпилированный в форму BMI и подключаемый через import <vector>;. Он убирает стоимость повторного парсинга, но его макросы, в отличие от именованного модуля, доходят до потребителя — это мост миграции, не полная инкапсуляция.

Раздел — это именованный подюнит одного модуля, записываемый как export module math:basic;. Разделы позволяют разбить большой модуль на файлы, по-прежнему предъявляя потребителю один модуль. Первичный интерфейс собирает их, часто через export import :basic;.

Мигрируйте инкрементально, снизу вверх: начните с leaf-библиотек без исходящих зависимостей, оборачивайте legacy-заголовки в глобальный фрагмент модуля и двигайтесь вверх по графу. Для непереведённых зависимостей берите header unit; нужна модуль-осведомлённая сборка вроде CMake 3.28+.

Если одна TU делает #include заголовка, а другая — import модуля, оборачивающего тот же код, одна сущность получает два определения разными путями. Они должны быть токен-в-токен идентичны; любое расхождение между заголовком и модулем — это нарушение ODR, часто молчаливое и непроверяемое.

BMI — это приватная сериализация внутреннего семантического представления одного компилятора; стандарт C++20 не определяет его формат. Он непереносим между компиляторами и часто между версиями одного и того же, поэтому каждый toolchain обязан пересоздать его из исходника.