Здравствуйте, 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>У меня рекурсивное определение: библиотека — это группа методов с схожим общим назначением и явно выраженной односторонней зависимостью от других библиотек.
Определение вроде вполне логичное, однако не полное — в плане отсутствия каких-либо упоминаний об интеграции с остальной (скажем так "клиентской") частью системы.
Здравствуйте, Dair, Вы писали:
D>(Я считаю, что h/hpp-only оно может быть в чисто темплейтном случае, а если есть нетемплейтный код, его надо выносить в код)
Ага, и link time code generation.
Иначе как ты будешь оптимизировать инлайновые функции?
Модуль реализуется примерно так — есть файл (или несколько файлов) с интерфейсной частью и частью реализации — после компиляции получается интерфейсный файл с зафиксированным форматом, который хранит интерфейсную часть модуля, и старый добрый объектный файл.
Так тоньше можно регулировать межмодульные зависимости, поскольку зависят теперь имена, а не файлы, можно точно указать какие имена импортируются и какие экспортируются. В случае с хидерами же все имена включённые в хидер теперь экспортируются, в результате количество зависимостей растёт как снежный ком. Это сильно влияет на время компиляции.
Для полной компиляции существенного выигрыша вроде быть не должно, однако я видел лекцию, где модули показали двукратное преимущество, а это неплохо, на мой взгляд. Но основное ускорение будет на инкрементальных билдах.
Далее, можно сильно уменьшить гранулярность импорта, поскольку сделать import xxx гораздо дешевле, чем #include xxx.h. В частности, STL предлагается поставлять примерно так <stl>, <stl/regex> и всё.
Далее, можно избавится от непортируемых и неудобных precompiled headers, unity builds итд.
Далее, поскольку фаза компиляции идёт строго после фазы препроцессинга, отловить циклические включения хидеров компилятором невозможно, а при использовании модулей — запросто.
Далее, кажется решили, что теперь имена в секции реализации имеют internal linkage — уменьшается кол-во нарушений ODR.
Ну и рискну предположить, что для чисто модульных проектов со временем введут запрет на circular dependencies и ODR violations, или вендоры их реализуют сами.
Далее, code completion tools — скорость их работы должна возрасти драматически, поскольку у них есть в наличии файлы интерфейса, а при изменении файла надо будет перепарсить только его.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Привет!
МР>Объясните, пожалуйста, в чем выражается эта нехватка модульной системы в C++? Все классы в отдельных единицах трансляции обычно находятся. Чего не хватает?
Здравствуйте, swingus, Вы писали:
S>Модуль реализуется примерно так — есть файл (или несколько файлов) с интерфейсной частью и частью реализации — после компиляции получается интерфейсный файл с зафиксированным форматом, который хранит интерфейсную часть модуля, и старый добрый объектный файл.
Спасибо! А можете объяснить как шаблоны будут храниться в модулях? Все равно будет текстовое (с помощью препроцессора) включение заголовочного файла с шаблоном во все единицы трансляции, где этот шаблон используется, и каждый раз шаблон будет компилироваться и будет генерироваться инстанциация шаблона?
Шаблоны так и будут храниться в интерфейсном файле и инстанцироваться в точке специализации. Но не включение препроцессором, а импорт, который недорого стоит. Я не знаю текущее состояние дел, но несколько лет назад проскакивали такие варианты:
— хранить полные специализации шаблонов на типах параметров, которые известны в точке объявления шаблона в объектном файле, соответствующем модулю, где объявлен шаблон, а остальные — в объектном файле, где шаблон инстанцирован;
— иметь некий глобальный относительно проекта кэш шаблонных специализаций.
В общем разумно предположить, что количество повторных инстанцирований будет уменьшено или сведено к нулю.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Спасибо! А можете объяснить как шаблоны будут храниться в модулях? Все равно будет текстовое (с помощью препроцессора) включение заголовочного файла с шаблоном во все единицы трансляции, где этот шаблон используется, и каждый раз шаблон будет компилироваться и будет генерироваться инстанциация шаблона?
Перекуём баги на фичи!
