Мне было очень странно и непонятно видеть такой факт: название модуля никак не связано с названием файла, как это принято в Java, Python и т. д. Cпециально, чтобы в примере подчеркнуть это, я назвал модуль M, а файл foo.cppm.
Поэтому, если вы заранее руками не предкомпилировали модуль и не назвали его нужным образом, то компилятор никогда в жизни не поймёт, что модуль M нужно искать в foo.cppm, если вы просто попросили его скомпилировать bar.cpp, зависящий от M.
И это по всей видимости, проблема именно Стандарта.
Давайте подумаем в теории. Все декларации, которые экспортирует модуль должны быть module linkage. Для экспорируемых функций из DLL/so применяется свой нестандартный linkage.
Поэтому логично предположить, что те функции, которые экспортирует DLL, не могут быть экспортируемы в смысле модуля. По-видимому, необходим всё равно h-файл. Но ничто не мешает в модуле определять эти функции. И кстати, инклюдить h-файл тоже ничего не мешает.
Увы, практика показывает обратное. Clang по умолчанию не воспринимает файл с расширением, отличным от .cppm как модуль. Для предкомпиляции нужно указывать дополнительные флаги -x c++-module:
Да. всё верно, в таком случае, он в фоне скомпилит и слинкует сразу три файла: g++ main.cpp a.cpp b.cpp
Правда если вы потом захотите собрать другую программу, частично перекрывающуюся с приведённой, то файлы a.cpp и b.cpp компилятору придётся пересобрать: g++ main2.cpp a.cpp b.cpp
В этом ничего страшного нет, поскольку такой юзкес редкий — если требуется переиспользовать объектные файлы, их обычно архивируют в статическую библиотеку.
Но вот с модулями переиспользование — это юзкейс частый. Если компилер будет по предкомпилировать всё в фоне, то профит ускорения компиляции потеряется.
Тоже были такие мысли. Но когда начинаешь думать «А как надо было», то ничего лучше придумать не получается) Если есть идеи — велком, интересно послушать
Если не ошибаюсь, при других расширениях нужно указывать доп. флаги. Как например, компилеры отличают код C от C++ по расширению, хотя это фиксится флагами. Теперь с модулями похожая история. Только расширения неконсистентные. Но могу ошибаться конечно.
Если вы про идею модулей, то да, есть проблемы… Особенно огорчает, что в разных компиляторах уже сразу неконсистетность… Например, разные дефолтные расширения файлов в VS и Clang
Class template argument deduction ещё киллер-фича 17-х плюсов)
Но подождите следующих 5 статей цикла, там ещё куча крутого. Совсем скоро будем не мочь жить без C++20)
Мне их тоже нигде не удалось протестить. Но без них в Clang пробовал — работает)
Кстати, интересно ещё попробовать import std.core; в clang. Он же на Винде использует стандартную библиотеку из Студии, а там std.core уже реализовали (правда эксперементально)
Вы правы! Но если Стандарт таков, что удобную реализацию сделать очень трудно, то это становится проблемой Стандарта… А сейчас он скорее таков: идея в том, чтобы обрабатывать Module interface unit и Header unit и складывать результаты обработки куда-нибудь на диск. Иначе, почти весь профит от использования модулей пропадает. Вопрос: в какой момент это будет делаться? Если автоматически во время компиляции зависимого модуля, то может возникнуть конфликт при одновременной сборке нескольких файлов…
А если не автоматически, то это и есть предкомпиляция.
Также это несколько противоречит идеологии существующих компиляторов, если им придётся самостоятельно генерить много промежуточных файлов, И использовать некий «кеш». Хотя это уже меньшая проблема.
Насколько я понимаю, это разные юниты. Но дробления мы избегали чтобы не компилировать хедеры каждый раз, вместе с каждым маленьким юнитом — я больше не могу придумать причин, чтобы избегать большого кол-ва маленьких cpp-шек.
Модули как раз решают эту проблему. Можно сделать много Module implementation unit, и это будет скорее всего почти настолько же быстро, как и один большой Module interface unit
Поэтому, если вы заранее руками не предкомпилировали модуль и не назвали его нужным образом, то компилятор никогда в жизни не поймёт, что модуль M нужно искать в foo.cppm, если вы просто попросили его скомпилировать bar.cpp, зависящий от M.
И это по всей видимости, проблема именно Стандарта.
Поэтому логично предположить, что те функции, которые экспортирует DLL, не могут быть экспортируемы в смысле модуля. По-видимому, необходим всё равно h-файл. Но ничто не мешает в модуле определять эти функции. И кстати, инклюдить h-файл тоже ничего не мешает.
$ clang++ -fmodules-ts -std=c++20 --precompile foo2.cppm -o K.pcm
$ clang++ -fmodules-ts -std=c++20 --precompile foo2.xxx -o K.pcm
clang++: warning: foo2.xxx: 'linker' input unused [-Wunused-command-line-argument]
clang++: warning: argument unused during compilation: '-fmodules-ts' [-Wunused-command-line-argument]
clang++: warning: argument unused during compilation: '-std=c++20' [-Wunused-command-line-argument]
$ clang++ -fmodules-ts -std=c++20 --precompile -x c++-module foo2.xxx -o K.pcm
g++ main.cpp a.cpp b.cppПравда если вы потом захотите собрать другую программу, частично перекрывающуюся с приведённой, то файлы a.cpp и b.cpp компилятору придётся пересобрать:
g++ main2.cpp a.cpp b.cppВ этом ничего страшного нет, поскольку такой юзкес редкий — если требуется переиспользовать объектные файлы, их обычно архивируют в статическую библиотеку.
Но вот с модулями переиспользование — это юзкейс частый. Если компилер будет по предкомпилировать всё в фоне, то профит ускорения компиляции потеряется.
Но подождите следующих 5 статей цикла, там ещё куча крутого. Совсем скоро будем не мочь жить без C++20)
Спасибо!
Мне их тоже нигде не удалось протестить. Но без них в Clang пробовал — работает)
Кстати, интересно ещё попробовать import std.core; в clang. Он же на Винде использует стандартную библиотеку из Студии, а там std.core уже реализовали (правда эксперементально)
А если не автоматически, то это и есть предкомпиляция.
Также это несколько противоречит идеологии существующих компиляторов, если им придётся самостоятельно генерить много промежуточных файлов, И использовать некий «кеш». Хотя это уже меньшая проблема.
Модули как раз решают эту проблему. Можно сделать много Module implementation unit, и это будет скорее всего почти настолько же быстро, как и один большой Module interface unit