У меня есть куча проектов, в которых все могут делиться "общей" статической библиотекой классов.
Что меня смущает, если я создаю статическую библиотеку из этих классов и свяжусь с ней в своих проектах, мне все же нужны заголовки классов в статической библиотеке в моих основных проектах.
В чем преимущество статической библиотеки?
Как компании, подобные Adobe, справляются с этим?
Статические библиотеки позволяют создавать библиотеку и использовать эту библиотеку во многих проектах.
Необходимость в файлах заголовков:
Поскольку проект с использованием библиотеки запрограммирован и скомпилирован независимо от библиотеки, эта программа должна знать объявление того, что вы используете. В противном случае, как бы ваш компилятор знал, что вы пишете действительный код?
Компилятор использует только исходный код для ввода и производит вывод. Это не касается скомпилированных объектных файлов или статических библиотек на входе.
Необходимость связывания в библиотеке:
Таким образом, если заголовки позволяют писать действительный код в вашем проекте, но когда дело доходит до времени ссылки, вам необходимо предоставить определение, которое содержится внутри статической библиотеки.
Компонент принимает все объектные файлы (скомпилированный код), а также все статические библиотеки и создает исполняемый файл или двоичный файл.
Дополнительная информация о статических библиотеках (преимущества, сравнение динамических и т.д.):
Кроме всего прочего, приятно разделить проект на библиотеки, чтобы в итоге не было 1 огромный монолитный проект.
Вам не нужно распространять исходный код (обычно в файлах .cpp) таким образом.
Если бы вы просто включили все .cpp файлы в каждый проект, который использовал общую библиотеку, тогда вам приходилось собирать файлы .cpp каждый раз.
Преимущество статических библиотек в динамических библиотеках заключается в том, что вы всегда можете быть уверены, что ваши программы будут автономными и что они используют правильную версию библиотеки (поскольку они скомпилированы в сам исполняемый файл). У вас также будет небольшое преимущество перед динамической компоновкой.
Недостатки статических библиотек в динамических библиотеках включают в себя то, что размер ваших файлов будет больше, потому что каждый исполняемый файл нуждается в собственной копии и что вы не можете поменять другую версию библиотеки, так как она не динамически загружена.
На ваш вопрос: как компании справляются с этим:
Типичная компания будет широко использовать как статические, так и динамические библиотеки.
Типичным способом использования статической библиотеки является наличие в вашем Makefile цели (или любой другой системы сборки), которая устанавливает заголовки в соответствующее место одновременно с установкой библиотеки.
Итак, ваша статическая библиотека заканчивается в /usr/local/lib, а заголовки входят в /usr/local/include или где угодно.
Кроме того, по сравнению с привязкой к объектным файлам, связывание с статической библиотекой может привести к меньшему окончательному исполняемому файлу. Причина этого заключается в том, что если вы не вызываете какие-либо функции из определенного объектного файла (включенного в статическую библиотеку), компоновщик не будет включать код для этих функций в вашем окончательном исполняемом файле. См. Внешняя связь с библиотекой