статическая библиотека, но мне все еще нужны заголовки?

Question

У меня есть несколько проектов, в которых все могут использовать «общую» статическую библиотеку классов.

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

В чем тогда преимущество статической библиотеки?

Как компании, такие как Adobe, справляются с этим?

Answer 1

Статические библиотеки позволяют создавать библиотеки и использовать эту библиотеку во многих проектах.

Необходимость заголовочных файлов:

Поскольку проект, использующий библиотеку, программируется и компилируется независимо от библиотеки, эта программа должна знать декларацию того, что вы используете. Иначе как ваш компилятор узнает, что вы пишете правильный код?

Компилятор принимает только исходный код в качестве ввода и производит вывод. Он не имеет дело с скомпилированными объектными файлами или статическими библиотеками на входе.

Необходимость ссылок в библиотеке:

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

Компоновщик принимает все объектные файлы (скомпилированный код), а также все статические библиотеки и создает исполняемый или двоичный файл.

Дополнительная информация о статических библиотеках (преимущества, сравнение динамических и т. Д.):

Помимо всего прочего, неплохо бы разделить ваш проект на библиотеки, чтобы у вас не получился 1 огромный монолитный проект.

Вам не нужно распространять исходный код (обычно в .cpp файлах) таким образом.

Если бы вы просто включили все файлы .cpp в каждый проект, в котором использовалась общая библиотека, вам пришлось бы каждый раз компилировать файлы .cpp.

Преимущество статических библиотек перед динамическими библиотеками заключается в том, что вы всегда можете быть уверены, что ваши программы будут автономными и что они используют правильную версию библиотеки (поскольку они скомпилированы в сам исполняемый файл). Вы также будете иметь небольшое преимущество в скорости перед динамическим соединением.

Недостатки статических библиотек перед динамическими библиотеками заключаются в том, что размеры ваших файлов будут больше, поскольку каждому исполняемому файлу требуется своя копия, и что вы не можете поменять другую версию библиотеки, поскольку она не загружается динамически.

Re ваш вопрос: Как компании справляются с этим:

Типичная компания будет широко использовать как статические, так и динамические библиотеки.

Answer 2

Типичный способ использования статической библиотеки - наличие в вашем Makefile цели (или любой другой используемой вами системы сборки), которая устанавливает заголовки в соответствующее место одновременно с установкой библиотеки.

Итак, ваша статическая библиотека заканчивается в / usr / local / lib, а заголовки попадают в / usr / local / include или куда угодно.

Answer 3

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