почему не все c++ библиотеки header-only?
Почему не все c++ библиотеки header-only? Даже Boost предоставляет часть функционала в виде header-only библиотек, а часть в виде скомпилированных. И возникает 2 вопроса:
- Есть ли какие то ограничения у header-only библиотек?
- Какой тип и когда лучше использовать?
Ответы (2 шт):
Почему не все c++ библиотеки являются header-only, можно понять, рассмотрев их плюсы и минусы
Плюсы использования header-only библиотек:
Позволяют упростить доставку библиотек для клиента, так как клиент сам сможет скомпилировать для себя исходный файл с нужными настройками под нужную платформу.
Позволяет компилятору делать больше оптимизаций, в частности inline, что невозможно при разделении библиотек на файлы реализации и интерфейса, но вы подвергаетесь риску раздувания исполняемого кода из-за использования этого заголовочного файла во многих единицах трансляции, но большинство компиляторов умны и могут избегать этого.
При добавлении header-only в проект требуется только include-paths.
Недостатки использования header-only библиотек:
Вы не можете скрыть детали реализации, как этого можно добиться при разделении библиотеки на интерфейс в виде
.hфайла и файла реализации поставляемого например в виде.lib,.dll.Большинство изменений в библиотеке потребует перекомпиляции всех единиц компиляции, использующих эту библиотеку.
Более длительное время компиляции, так как компилятор должен видеть реализацию всех компонентов во включенных файлах, а не только их интерфейсы.
усложняется чтение кода, так как клиенту проще видеть только интерфейс используемого функционала и не отвлекаться на реализацию (спорное утверждение).
Нельзя слинковать динамически = нельзя заменить/обновить библиотеку в уже скомпилированной программе.
Когда от использования header-only библиотек ни куда не деться:
- При использовании шаблонов (
template) включение определений в заголовок является единственным способом компиляции (если явного инстанцирования шаблонов недостаточно), так как компилятор должен знать полное определение шаблонов, чтобы инстанцировать шаблон.
Исходя из всего вышесказанного каждый может сделать для себя вывод, использовать header-only или нет, я же считаю, что использование header-only библиотеки не самое лучшее решение в большинстве случаев, если вам только не требуются шаблоны или inline функции.
Плюсы header-only библиотек фактически сводятся только к удобству их использования. И программистам они очень нравятся. А вот для конечного продукта - это довольно спорная возможность языка.
Думаю многие заметили как разбух исполняемый код многих программ. Зачастую он измеряется гигабайтами, и с каждой новой версией программного продукта чуть ли не удваивается, хотя приращение функционала практически не замечается (в основном меняется дизайн интерфейса для маркетинговых целей).
Причина неимоверного разбухания исполняемого кода кроется именно в header-only библиотеках.
Хотя компилятор и не включает повторный header код (#ifndef ... #define ...), но это происходит только для единицы компиляции, т.е. для объектного файла. Но каждый исполняемый файл (.exe, .dll, ...) линкуется из множества объектных файлов. Программный продукт бывает состоит из тысяч исполняемых. Т.е. происходит много-тысячное дублирование кода.