Re[3]: C++'s lack of a module system
От: Dair Россия  
Дата: 20.05.18 05:17
Оценка:
Здравствуйте, Максим Рогожин, Вы писали:

МР>Можете объяснить откуда берется много исполняемого кода в modern C++ headers?


У меня ощущение (но точно не скажу), что это дань моде. А моду диктуют всякие недоязыки вроде JavaScript.
Re[5]: C++'s lack of a module system
От: AlexGin Беларусь  
Дата: 20.05.18 07:44
Оценка:
Здравствуйте, Dair, Вы писали:

AG>>Да, обычная. Но стандартного (с точки зрения языка C++) метода применнинея библиотекам — нет.


D>А что, нужен? А зачем? Вообще давно придумали статические и динамические библиотеки, они, конечно, вне стандарта C++, но зачем это втаскивать в него, когда это вещи, зависящие от операционной система?

Вопрос: Стандарт нужен ли и зачем? — скорее риторический. Вот сделают и посмотрим, какие проблемы это решит.
Так, например, если бы то, что реализовано в том же C++11, мне показали лет десять назад, я точно также бы усомнился — надо ли это?
Тем не менее, теперь — охотно пользуюсь, и недоумеваю — как ранее работали без этого

AG>>То есть — это может быть только один заголовочник (*.h либо *.hpp файл).

AG>>Это может быть *.lib (статическая библиотека) с *.h файлом (файлами).

D>А вот какая разница? Как удобно разработчику — так и сделано.

Здесь подразумевается два разработчика — разработчик библиотечного модуля и разработчик продукта, в котором применяется данный модуль.
То, что удобно первому, далеко не всегда удобно второму и наоборот.

D>(Я считаю, что h/hpp-only оно может быть в чисто темплейтном случае, а если есть нетемплейтный код, его надо выносить в код)

+100500
В то же время, теперь часто в h/hpp выносят много кодогенерации (мне самому это не нпавится, но приходиться мириться).

D>Внутри компании библиотеки должны распространяться в исходных кодах, и пусть каждый проект из них делает то, что им надо — статическую библиотеку, динамическую, напрямую в проект влинковывает.


Смотря в какой компании. Здесь всё зависит от принятой в компании политики. Далеко не всегда одно подразделение делится исходниками с другим.

AG>>Также это может быть *.dll файл (как собственно DLL, так и в виде COM-компонента, исполненного в виде dll).

AG>>Что стандартно?

D>Стандартно отсутствие стандарта. Как хочешь — так и делай, решай сам, у тебя голова на плечах.


Так зачем мы сегодня с радостью пользуемся всм тем, что привнесли в нашу жизнь стсандарты C++11/14, зачем изучаем C++17?
Давай писать на C++ образца 1983 года...

AG>>Так определи понятие "библиотека" для C++

AG>>Что ты сам понимаешь под этим термином в контексте C++?

D>У меня рекурсивное определение: библиотека — это группа методов с схожим общим назначением и явно выраженной односторонней зависимостью от других библиотек.

Определение вроде вполне логичное, однако не полное — в плане отсутствия каких-либо упоминаний об интеграции с остальной (скажем так "клиентской") частью системы.
Отредактировано 20.05.2018 7:57 AlexGin . Предыдущая версия . Еще …
Отредактировано 20.05.2018 7:50 AlexGin . Предыдущая версия .
Re[5]: C++'s lack of a module system
От: Кодт Россия  
Дата: 21.05.18 10:39
Оценка:
Здравствуйте, Dair, Вы писали:

D>(Я считаю, что h/hpp-only оно может быть в чисто темплейтном случае, а если есть нетемплейтный код, его надо выносить в код)


Ага, и link time code generation.
Иначе как ты будешь оптимизировать инлайновые функции?
Перекуём баги на фичи!
Re: C++'s lack of a module system
От: swingus  
Дата: 22.05.18 02:00
Оценка: 2 (1)
Модуль реализуется примерно так — есть файл (или несколько файлов) с интерфейсной частью и частью реализации — после компиляции получается интерфейсный файл с зафиксированным форматом, который хранит интерфейсную часть модуля, и старый добрый объектный файл.
Так тоньше можно регулировать межмодульные зависимости, поскольку зависят теперь имена, а не файлы, можно точно указать какие имена импортируются и какие экспортируются. В случае с хидерами же все имена включённые в хидер теперь экспортируются, в результате количество зависимостей растёт как снежный ком. Это сильно влияет на время компиляции.
Для полной компиляции существенного выигрыша вроде быть не должно, однако я видел лекцию, где модули показали двукратное преимущество, а это неплохо, на мой взгляд. Но основное ускорение будет на инкрементальных билдах.
Далее, можно сильно уменьшить гранулярность импорта, поскольку сделать import xxx гораздо дешевле, чем #include xxx.h. В частности, STL предлагается поставлять примерно так <stl>, <stl/regex> и всё.
Далее, можно избавится от непортируемых и неудобных precompiled headers, unity builds итд.
Далее, поскольку фаза компиляции идёт строго после фазы препроцессинга, отловить циклические включения хидеров компилятором невозможно, а при использовании модулей — запросто.
Далее, кажется решили, что теперь имена в секции реализации имеют internal linkage — уменьшается кол-во нарушений ODR.
Ну и рискну предположить, что для чисто модульных проектов со временем введут запрет на circular dependencies и ODR violations, или вендоры их реализуют сами.
Далее, code completion tools — скорость их работы должна возрасти драматически, поскольку у них есть в наличии файлы интерфейса, а при изменении файла надо будет перепарсить только его.

Здравствуйте, Максим Рогожин, Вы писали:

МР>Привет!


МР>Объясните, пожалуйста, в чем выражается эта нехватка модульной системы в C++? Все классы в отдельных единицах трансляции обычно находятся. Чего не хватает?
Re[2]: C++'s lack of a module system
От: Максим Рогожин Россия  
Дата: 22.05.18 15:40
Оценка:
Здравствуйте, swingus, Вы писали:

S>Модуль реализуется примерно так — есть файл (или несколько файлов) с интерфейсной частью и частью реализации — после компиляции получается интерфейсный файл с зафиксированным форматом, который хранит интерфейсную часть модуля, и старый добрый объектный файл.


Спасибо! А можете объяснить как шаблоны будут храниться в модулях? Все равно будет текстовое (с помощью препроцессора) включение заголовочного файла с шаблоном во все единицы трансляции, где этот шаблон используется, и каждый раз шаблон будет компилироваться и будет генерироваться инстанциация шаблона?
Re[3]: C++'s lack of a module system
От: swingus  
Дата: 22.05.18 18:02
Оценка:
Шаблоны так и будут храниться в интерфейсном файле и инстанцироваться в точке специализации. Но не включение препроцессором, а импорт, который недорого стоит. Я не знаю текущее состояние дел, но несколько лет назад проскакивали такие варианты:
— хранить полные специализации шаблонов на типах параметров, которые известны в точке объявления шаблона в объектном файле, соответствующем модулю, где объявлен шаблон, а остальные — в объектном файле, где шаблон инстанцирован;
— иметь некий глобальный относительно проекта кэш шаблонных специализаций.
В общем разумно предположить, что количество повторных инстанцирований будет уменьшено или сведено к нулю.

Здравствуйте, Максим Рогожин, Вы писали:

МР>Спасибо! А можете объяснить как шаблоны будут храниться в модулях? Все равно будет текстовое (с помощью препроцессора) включение заголовочного файла с шаблоном во все единицы трансляции, где этот шаблон используется, и каждый раз шаблон будет компилироваться и будет генерироваться инстанциация шаблона?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.