C++ modules в 2026 — стоит ли переходить или ждать пока устаканится?

[GpuGuru]

Ведём крупный C++ проект, около 2 миллионов строк, CMake + GCC/Clang. Смотрим на C++20 modules уже полтора года, но всё время что-то мешало: то поддержка в компиляторах была сырая, то CMake не умел нормально. Сейчас 2026, GCC 15, Clang 19, CMake 3.30+ — стало ли это рабочим или всё ещё эксперимент? Особенно интересует опыт тех кто реально мигрировал большой кодовой базой.

[kernel_veteran]

Короткий ответ: стандартная библиотека через import std работает стабильно начиная с MSVC 19.36+ и Clang 18 с libc++. GCC с модулями всё ещё капризничает на сложных шаблонах — натыкались на ICE (Internal Compiler Error) на GCC 14, в 15 стало лучше но не идеально. Для нового кода на небольших проектах — да, можно. Для миграции 2 миллионов строк — не сейчас.

[m3power]

Главная проблема миграции — это не компиляторы, а инструментарий вокруг. clang-tidy с модулями работает нестабильно. Ряд статических анализаторов (PVS-Studio, cppcheck) поддерживают modules частично. IDE-шки: CLion с CMake 3.30 более-менее справляется, но автодополнение в module interface units до сих пор периодически глючит. Это убивает продуктивность команды.

[roman2026]

Прагматичный подход который мы используем: новые компоненты пишем с модулями, старый код оставляем на хедерах. Модули и хедеры вполне сосуществуют через header units и module import. Это позволяет накопить опыт и не рисковать сроками. Через год-два когда инструментарий дозреет — можно будет мигрировать старый код итерационно.

[mstrbates]

Что реально даёт переход на модули прямо сейчас: время инкрементальной сборки. У нас небольшой проект ~200к строк, после перехода на modules для 40% кода — инкрементальная пересборка ускорилась в 2.5 раза. Полная пересборка немного медленнее из-за того что компилятор делает больше работы при первом проходе. На CI где всегда полная сборка — почти без изменений.

[asynclover]

Для тех кто на Windows и MSVC — там ситуация лучше всего. Microsoft вложила в модули больше ресурсов и у них самый зрелый CMake интроп. Если ваша команда на Linux с GCC — я бы подождал GCC 15.2 или 16. Clang на Linux — уже неплохо но нужен libc++ а не libstdc++, что может быть проблемой если проект давно на GNU toolchain.

[burnedblueteam]

@mstrbates, про 'полная пересборка немного медленнее' — у нас на CI это вылезло жёстче, чем звучит. Добавляется отдельный шаг сканирования зависимостей модулей (CMake гоняет компилятор в режиме определения deps до самой сборки), и на большом дереве этот скан сам по себе не бесплатный. Инкрементально выигрываешь честно, а на чистой сборке в CI можно даже уйти в минус. Так что твою цифру 2.5х надо сразу делить по сценарию: локальная разработка — да, CI с нуля считай отдельно.

[vlad98]

Один практический затык, на который натыкаются почти все при старте на CMake: для модулей обязателен генератор Ninja (1.11+), под Make динамические зависимости модулей не работают в принципе. Если на ваших 2 миллионах строк сборка завязана на Makefile-генератор, это отдельный кусок миграции ещё до того, как вы тронете первый .cppm.

[maja33]

@roman2026, сосуществование через header units на словах красиво, но на практике это самая хрупкая часть схемы. Header units по-разному кешируются в GCC и Clang, и любой макрос, определённый до импорта, ломает воспроизводимость сборки. Мы плюнули и для STL пошли через import std целиком, а свои легаси-хедеры оставили обычным include внутри global module fragment. Меньше сюрпризов, чем городить header unit на каждый vector.