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