Модули С++
Исследовал состояние модулей на 17.11.18. Пишу эту заметку прежде всего для закрепления понимания концепции и формирования мнения. Настоящий программист C++ ведь должен иметь мнение на любую тему 😀
Статья за модули - https://build2.org/article/cxx-modules-misconceptions.xhtml
Статья против модулей - https://izzys.casa/posts/millennials-are-killing-the-modules-ts.html
Поддержка в компиляторах:
Clang - https://clang.llvm.org/docs/Modules.html
Gcc - https://gcc.gnu.org/wiki/cxx-modules
MSVC - https://blogs.msdn.microsoft.com/vcblog/2017/05/05/cpp-modules-in-visual-studio-2017/
Конспект:
В отличие от подключения хеадеров, подключение модуля требует генерации дополнительного файла "binary module interface (BMI)" таким образом, если один модуль импортирует другой модуль, прежде всего, нужно получить BMI импортируемого модуля. По факту, при компиляции модуля, у нас на выходе два файла a.o и a.bmi.
Одна из основных проблем - как понять, какие файлы компилировать, ведь модуль не задает пути к файлу. Кто будет это решать? По сути - bmi это и есть хеадер, но он должен быть сгенерирован прежде чем его будет возможно найти и путь к нему заранее неизвестен. Таким образом получается, нам нужно выполнить следующую последовательность действий:
1. Сгенерировать .bmi и собрать .o для всех новых файлов в проекте
2. Запомнить отношение исходников к bmi для последующей пересборки
3. При изменении исходника, пересобирать соответствующий bmi и другие исходники, которые зависят от этого bmi
Пример:
a.cpp
b.cpp
Makefile
Хорошо, а как с хеадерами происходит? Система сборки ведь тоже не знает, от каких хеадеров зависит cpp, пока не спросит компилятор, передав ключ -M. Компилятор знает пути к хеадерам, потом без проблем может выдать список путей. А как с модулями? Видимо, комплиятор должен выдать список модулей, от которого зависит cpp. Система сборки должна будет прошерстить bmi файлы (или свой кэш) и понять зависимости.
В общем, мой вывод такой. Неприкольно, что приходится навязывать системам сборки новые правила, так как они устоялись еще с времен Си и на сколько я понимаю, с тех пор не менялись. Грубо говоря, для сборки новых плюсов понадобится новая система сборки. С другой стороны, плюсы такого решения перевешивают минусы. Мы получим ускорение сборки, сделав этот сложный шаг. Думаю, года через 3 можно будет начать пытаться использовать модули в своих проектах, а через лет 7, никаких препятствий для этого не останется.
Статья за модули - https://build2.org/article/cxx-modules-misconceptions.xhtml
Статья против модулей - https://izzys.casa/posts/millennials-are-killing-the-modules-ts.html
Поддержка в компиляторах:
Clang - https://clang.llvm.org/docs/Modules.html
Gcc - https://gcc.gnu.org/wiki/cxx-modules
MSVC - https://blogs.msdn.microsoft.com/vcblog/2017/05/05/cpp-modules-in-visual-studio-2017/
Конспект:
В отличие от подключения хеадеров, подключение модуля требует генерации дополнительного файла "binary module interface (BMI)" таким образом, если один модуль импортирует другой модуль, прежде всего, нужно получить BMI импортируемого модуля. По факту, при компиляции модуля, у нас на выходе два файла a.o и a.bmi.
Одна из основных проблем - как понять, какие файлы компилировать, ведь модуль не задает пути к файлу. Кто будет это решать? По сути - bmi это и есть хеадер, но он должен быть сгенерирован прежде чем его будет возможно найти и путь к нему заранее неизвестен. Таким образом получается, нам нужно выполнить следующую последовательность действий:
1. Сгенерировать .bmi и собрать .o для всех новых файлов в проекте
2. Запомнить отношение исходников к bmi для последующей пересборки
3. При изменении исходника, пересобирать соответствующий bmi и другие исходники, которые зависят от этого bmi
Пример:
a.cpp
import moduleB;
b.cpp
export moduleB;
Makefile
a.o : a.cpp, b.bmi << Кто будет прописывать это? Система сборки?
b.o : b.cpp
b.bmi : b.cpp
Хорошо, а как с хеадерами происходит? Система сборки ведь тоже не знает, от каких хеадеров зависит cpp, пока не спросит компилятор, передав ключ -M. Компилятор знает пути к хеадерам, потом без проблем может выдать список путей. А как с модулями? Видимо, комплиятор должен выдать список модулей, от которого зависит cpp. Система сборки должна будет прошерстить bmi файлы (или свой кэш) и понять зависимости.
В общем, мой вывод такой. Неприкольно, что приходится навязывать системам сборки новые правила, так как они устоялись еще с времен Си и на сколько я понимаю, с тех пор не менялись. Грубо говоря, для сборки новых плюсов понадобится новая система сборки. С другой стороны, плюсы такого решения перевешивают минусы. Мы получим ускорение сборки, сделав этот сложный шаг. Думаю, года через 3 можно будет начать пытаться использовать модули в своих проектах, а через лет 7, никаких препятствий для этого не останется.
Комментарии
Отправить комментарий